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SUMMARY 


* 


This  paper  documents  the  year-long  efforts  of  a  multidisciplinary  design  team  to 
design,  build,  and  support  an  autonomous  aerial  robotics  system.  The  system  was 
developed  to  participate  in  the  Assocation  for  Unmanned  Vehicle  System’s  (AUVS)  First 
International  Aerial  Robotics  Competition  which  was  held  in  Atlanta,  Georgia  on  the 
Georgia  Tech  campus  on  July  29th,  1991. 

As  development  time  and  budget  were  extremely  limited,  the  team  elected  to  attempt 
the  design  using  concurrent  engineering  design  methods.  These  methods  were  validated  in 
an  IDA  study  by  Winner  [1]  in  the  late- 1980s  to  be  particularly  adept  at  handling  the 
difficulties  to  design  presented  by  these  limitations. 

A  significant  portion  of  the  team’s  early  efforts  were  aimed  at  establishing  an 
appropriate  design  environment:  understanding  the  problem  and  soliciting  necessary 
resources.  Market  evaluations  of  candidate  hardware  components  occupied  the  team  for 
most  of  the  initial  design  cycle,  with  selection  ce  an  aerial  vehicle,  the  Pacific  RPV 
'Bruiser',  accomplished  in  late-November  1990. 

With  receipt  and  evaluation  of  the  system's  base,  the  aerial  vehicle,  preliminary 
design  of  a  variety  of  payload  components  was  initiated  in  January  1991.  Many  of  these 
subsystems  were  designed  from  the  'ground  up',  while  some  components  were  loaned  to 
the  team  and  modified  for  the  competition's  specific  requirements.  Flight  testing  with  the 
aerial  vehicle  revealed  a  number  of  mechanical  problems  with  the  aircraft’s  design  and 
manufacture.  These  difficulties  eventually  trickled  into  test  schedules  and  system-level 


x 


planning  documents,  making  any  long-term  component  testing,  validation,  and  integration 
impossible. 

Even  with  the  Bruiser's  difficulties,  significant  work  on  all  major  subsystems  was 
accomplished,  although  integration  of  these  components  into  a  working  system  was  still  in 
its  infancy  on  competition  day.  Further  mechanical  malfunctions  of  the  aircraft,  difficulties 
with  communications  nodes,  and  immaturity  of  other  components  forced  the  team's 
withdrawal  from  the  event,  but  not  before  an  all  out  effort  was  made  up  until  called  for  their 
heat  on  competition  day. 

The  team,  while  accomplishing  a  large  portion  of  the  design  task,  was  less  than 
successful  in  implementing  all  facets  of  concurrent  engineering.  While  under  budget,  the 
system's  quality,  as  judged  by  the  AUVS  on  Quality  Function  Deployment  documents, 
was  lower  than  other  competing  systems  in  six  of  seven  listed  customer  categories.  Lastly, 
although  the  competition-prescribed  design  cycle  deadlines  were  not  met,  none  of  the  five 
competing  team's  produced  a  system  capable  of  completing  any  significant  portion  of  the 
mission,  possibly  indicating  an  unrealistic  product  development  cycle  from  the  beginning. 

Regardless,  application  of  several  different  quality  engineering  tools  was 
accomplished,  although  without  significant  thought  as  to  their  timing  in  the  development 
cycles  and  the  results  intended  from  the  use  of  each  tool.  The  team  worked  from  beginning 
to  near  project  completion  in  a  'design  deficit’,  having  fewer  resources  than  required  to 
accomplish  the  remaining  portions  of  the  system's  design. 

All  in  all,  the  hand-on  experience  and  interface  with  a  variety  of  technical  specialties 
represented  on  the  design  team  resulted  in  a  positive  experience.  Lessons  learned,  one  of 
the  ten  tenets  of  successful  concurrent  engineering  implementation,  have  been  focused  on 
in  order  to  provide  impetus  to  next  year's  design  team. 
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INTRODUCTION 


Why  Undertake  Development  of  an  Aerial  Robot? 


In  late-July  1990,  the  Association  for  Unmanned  Vehicle  Systems  (AUVS) 
announced  the  First  International  Aerial  Robotics  Competition.  This  competition  took  place 
on  the  Georgia  Tech  campus  on  July  29th,  1991  and  exhibited  talents  of  five  student  design 
teams  from  major  engineering  universities  around  the  United  States. 

This  competition  required  development  of  an  unmanned  and  autonomous  aerial 
robot  system.  The  system  could  be  preprogrammed  or  intelligent,  but  was  not  to  be  flown 
by  a  student  operator.  Distribution  of  computational  power  within  the  system,  either 
airborne  or  at  a  ground  station,  was  left  to  the  team's  discretion.  Data  link  from  the  aerial 
vehicle  to  the  ground  could  be  accomplished  using  a  variety  of  means,  however,  no 
physical  tethers  or  other  'entangling  encumbrances’1  were  allowed.  The  competition- 
specified  mission  was  accomplished  completely  inside  a  volleyball  court  bordered  by  a 
black  polystyrene  plastic-covered  sand  floor,  rubber-coated  chain  link  fence  along  all  four 
sides,  and  monofilament  fishing  line  periodically  stretched  both  longitudinally  and  laterally 
across  the  top  of  the  court  (approximately  9.75  feet  above  the  arena  surface)  [Figure  1], 
The  aerial  vehicle  was 

1.  Association  for  Unmanned  Vehicle  Systems,  "Official  Rules",  Association  for 
Unmanned  Vehicle  Systems  First  International  Aerial  Robotics  Competition.  January  1991, 

p.  1. 
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Figure  1  -  First  International  Aerial  Robotics  Competition  Arena 


required  to  start  in  a  specified  area  adjacent  to  a  corner  of  the  court,  take  off,  and  transport 
as  many  metallic  target  disks  as  possible  from  one  six  foot  diameter  ring  to  another  within 
three  minutes.  A  wooden  barrier,  three  feet  in  height,  was  erected  across  the  center  of  the 
court,  and  existing  metal  poles,  used  normally  to  mount  a  volleyball  net,  were  left  as 
obstacles  to  movement  [Figures  2-4],  In  addition  to  the  three  minute  limitation  for 
executing  the  prescribed  mission,  an  additional  three  minutes  was  allotted  each  team  to  start 
their  aircraft,  and  a  final  three  minute  segment  allowed  to  set  up  external  navigation  cues  or 
control  stations,  as  required  by  the  various  systems. 

Disks  were  designed  so  that  a  variety  of  means  could  be  utilized  for  retrieval: 
tactile,  suction,  or  magnetic.  Two  circular  steel  plates,  three  inches  in  diameter,  were 
attached  to  the  top  and  bottom  of  a  3/8"  tall  aluminum  tube.  The  cavity  inside  the  tube  was 
filled  with  lead  shot  to  increase  each  disk's  weight  to  four  ounces.  Six  of  these  Day-Glo 
orange -colored  disks  [Figure  5]  were  randomly  distributed  within  the  'source'  bin. 

Vehicles  could  be  no  larger  than  six  feet  in  any  dimension,  although  telescoping 
arms,  appendages,  and  wings  could  be  deployed  once  airborne  and  not  violate  this 
restriction2.  A  safety  mechanism  was  also  required  which  could  terminate  system 
operation  should  the  aircraft  become  unstable  or  begin  substantial  uncommanded  deviation 
from  the  desired  flight  trajectory. 

The  unique  challenges  presented  by  this  competition  required  collaboration  of 
several  technical  disciplines  and  allowed  student  engineers  to  advance  designs  beyond  the 


2.  Association  for  Unmanned  Vehicle  Systems,  "Questions  and  Answers 
Concerning  the  First  International  Aerial  Robotics  Competition",  Association  for 
Unmanned  Vehicle  Systems  First  International  Aerial  Robotics  Competition.  January  1991, 

p.  1. 
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Figure  3  -  Aerial  V  iew  of  the  Arena  from  East  looking  West 


Figure  4  -  Ground  View  of  Arena  from  the  South  looking  North 
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Figure  5  -  Target  Disk  Geometry  and  Technical  Data 


preliminary  (primarily  paper)  stage.  Additionally,  multidisciplinary  requirements  of  the 
AUVS'  competition,  coupled  with  a  restrictive  one-year  design  cycle,  created  the  perfect 
laboratory'  environment  for  application  of  concurrent  engineering  principles. 

Various  management  and  engineering  design  courses  throughout  the  Georgia  Tech 
curriculum  individually  focus  on  the  study  and  application  of  these  techniques.  Few 
examples  were,  however,  available  which  showed  the  result  of  applying  concurrent 
engineering  tenets  at  the  conceptual  design  point  and  highlighted  their  ultimate  impact  on 
manufacturing,  operation,  and  support  of  a  hardware  component  or  system  downstream  in 


the  design  cycle. 


It  was  with  this  competition  and  the  opportunities  it  offered  as  a  backdrop,  that  a 
multi-year,  multi-phase  concurrent  engineering  pilot  project  was  initiated.  Phase  I 
objectives  were  to  develop  the  proposed  aerial  robot  system  toward  application  in  the 
AUVS  competition  environment.  Follow-on  phases  were  envisioned  to  use  this  baseline 
system  as  a  test  bed  for  applicable  emerging  technologies.  The  remainder  of  this  paper 
seeks  to  further  define  the  design  environment  and  chronicle  the  design  team's  phase  I 
efforts. 
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CHAPTER  I 


WHAT  IS  CONCURRENT  ENGINEERING  AND  WHY  WAS 
IT  SO  IMPORTANT  TO  THIS  PROJECT? 


Concurrent  Engineering 

Winner  [1]  defines  concurrent  engineering  as  a  "systematic  approach  to  the 
integrated,  concurrent  design  of  products  and  related  processes,  including  manufacture  and 
support.  This  approach  is  intended  to  cause  the  developers,  from  the  outset,  to  consider  all 
elements  of  the  product  life  cycle  from  conception  through  disposal,  including  quality, 
cost,  schedule,  and  user  requirements."3  More  recently,  Clausing  [2]  introduced  the 
concept  of  "world-class  concurrent  engineering",  which  he  described  as  a  combination  of 
"three  major  elements:  (1)  Management  (process,  organization,  and  people  styles);  (2) 
Enhanced  Quality  Function  Deployment  (EQFD);  and  (3)  Quality  Engineering  for  Robust 
Design."4 


3.  Robert  I.  Winner  et  al.,  "The  Role  of  Concurrent  Engineering  in  Weapons 
System  Acquisition",  Institute  for  Defense  Analyses  Report  R-338.  December  1988,  p.  2. 
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Concurrent  engineering,  in  order  to  be  successful,  requires  that  consideration  of 
processes  traditionally  ignored  until  later  in  the  product  development  cycle  are  included  as 
facts  bearing  on  the  problem  during  formulation  and  selection  of  design  options.  This 
necessarily  requires  communication  between  engineers  normally  isolated  within  their  'time 
segment'  of  the  design  process,  and  who  typically  speak  in  technical  languages  unfamiliar 
to  other  design  engineers.  Therefore,  management  capable  of  interpreting  input  from 
participants  in  product  design  and  manufacture,  and  managing  this  ’deluge’  of  information 
toward  a  common  design  goal,  is  imperative. 

Apparent  in  the  definitions  above  are  tenets  of  the  probably  more  recognizable 
systems  and  quality  engineering  disciplines. 

Systems  Engineering. 

Systems  engineering  evolved  out  of  the  need  to  manage  large,  very  complex,  highly 
technical  projects  conducted  over  severely  constrained  development  times.  Concurrently, 
the  emergence  of  technical  specialization  throughout  the  1950s  and  1960s  resulted  in  over 
250  recognized  specialties,  all  of  which  required  information  from,  and  provided  data  to, 
the  development  process.  Coordinating  this  exchange  required  significant  effort  by  the 
systems  engineering  and  technical  direction  coordinator,  and  resulted  in  the  need  for  a 
combined  technique  to  address  both  management  and  technical  processes  as  applied  to 
design5. 


4.  Don  Clausing,  "Concurrent  Engineering",  Design  and  Productivity 
International  Conference.  Honolulu,  Hawaii,  February  1991,  p.  1. 

5.  Defense  Systems  Management  College,  Systems  Engineering  Management 
Guide.  2nd  Edition,  December  1986,  p.  1.2. 
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Quality  Engineering. 


While  formal  systems  engineering  techniques  have  been  around  only  since  the 
1950s,  quality  engineering  methods  find  their  origins  in  the  early  1900s  with  the  industrial 
revolution6.  Engineering  drawings  and  informal  inspection  procedures  along  the 
manufacturing  line  gradually  yielded  to  the  more  formal  statistical  process  control  (SPC) 
techniques  initiated  during  the  1930s7.  While  traditionally  considered  applicable  only 
during  the  manufacturing  stage  of  a  product's  life  cycle,  studies  indicate  utility  from  their 
application  during  the  design  phase,  as  well  as  their  application’s  impact  on  design  in  an 
iterative  environment8.  These  methods  involve  data  collection  and  evaluation  of  processes 
and  product  characteristics  along  the  production  line. 

More  recent  are  the  Japanese  initiatives  in  quality  engineering.  Having  evolved 
over  the  last  thirty  to  forty  years,  these  techniques  are  less  tools,  and  more  underlying 
theme,  in  product  design  and  manufacture.  Total  Quality  Control  (TQC)  is  implemented  in 
every  department,  by  every  employee,  and  involves  improvement  of  everything  the 
company  attempts  to  do9. 

Some  quality  techniques,  while  applicable  during  the  manufacturing  stage,  are 
equally  useful  during  conceptual  design.  Taguchi  parameter  design  optimization  methods 
(PDOM)  attempt  to  identify  which  engineering  parameters  are  easiest  and  most  cost- 


6.  Winner  et  al.,  pp.  14-15. 

7.  Ibid.,  pp.  14-15. 

8.  Ibid.,  p.  14. 

9.  Yoshinori  Iizuka,  "The  Japanese  Way  of  TQC",  The  University  of  Tokyo, 
Presentation  Charts1  1  1  1  Japan  Study  Mission  Report,  1989,  p.  1. 
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effective  to  control  while  maintaining  a  requisite  product  quality  [2].  Quality  Function 
Deployment  (QFD),  a  graphical  mapping  technique  first  implemented  in  1972  at 
Mitsubishi's  Kobe  shipyard10,  aids  in  translating  customer  requirements  into  product  and 
process  characteristics  [3,4]. 

Putting  it  All  Together. 

A  useful  analogy  in  understanding  how  concurrent  engineering  incorporates  the 
best  of  systems  and  quality  engineering  is  a  road  network.  Concentrating  on  the  product 
design,  the  design  cycle  can  be  compared  to  the  route  which  must  be  negotiated  and  the 
engineering  techniques  to  the  road  system  over  which  various  design  and  manufacturing 
engineers  must  travel. 

Statistical  process  control  techniques  allow  the  manufacturing  engineer  to  'drive' 
from  downstream  in  the  design  only  as  far  as  the  beginning  of  the  production  cycle  before 
reaching  a  'dead  end'.  This  technique  is  primarily  a  management  action  and  not  one  in 
which  the  line  worker  will  likely  become  involved.  The  Japanese,  on  the  other  hand, 
through  implementation  of  methods  like  Taguchi  PDOM  and  QFD,  can  'drive'  along  the 
design  cycle  from  conceptual  design  through  product  manufacture  and  support  [Figure  6]. 
Because  quality  permeates  Japanese  organization  structure,  both  management  and  labor  are 
equally  affected,  represented  by  the  multi-tiered  highway. 

Systems  engineering  techniques  are  primarily  management  and  technologies 
processes  applied  early  in  the  design  and  applicable  through  the  product's  complete  life 
cycle11  [Figure  7]. 


10.  John  R.  Hauser  and  Don  Clausing,  "The  House  of  Quality",  Harvard  Business 
Review.  May-June  1988,  p.  63. 


1 1.  Defense  Systems  Management  College,  p.  1.2. 
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Concurrent  engineering  may  be  viewed  as  the  'junction'  of  these  techniques  within 
some  methodology  [Figure  8].  One  can  envision  the  clover- leaf  exchange  which  allows 
engineers  from  anywhere  in  the  design  or  manufacturing  process  access  to  any  other  point 
in  the  product's  development  cycle. 


Figure  8  -  'The  Concurrent  Engineering  Exchange' 


Key  to  successful  long-term  application  of  concurrent  engineering  is  a  fully- 
integrated  computer-aided  design  and  manufacturing  environment  [5].  An  automated 
design  environment  may  eventually  allow  engineers  the  ability  to  avoid  building  the  road', 
but  instead,  the  requirement  only  to  'model  the  road'  while  accomplishing  the  same  design 
goals. 
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The  Aerial  Robot's  Design  Environment 


A  design  environment  may  best  be  described  as  the  motivation  for,  and  resources 
available  to,  accomplish  a  given  design.  Having  already  discussed  the  AUVS-sponsored 
competition,  a  brief  overview  of  time,  manpower,  budget,  facilities,  and  team  experience 
follows. 

Time. 

Three- hundred  forty-three  (343)  design  days  were  available  from  the  team's  first 
organization  meeting  on  August  20th,  1990  to  competition  day  on  July  29th,  1991.  After 
subtracting  time  for  quarterly  class  breaks  and  holidays,  the  team  was  left  with  less  than 
forty-three  (43)  weeks  in  which  to  develop  the  system.  This  represents  a  best-case  design 
cycle  as  time  away  from  the  aerial  robotics  effort  to  pursue  other  academic  requirements 
(mid-term  and  final  examinations,  course  projects,  etc.)  are  not  included. 

Manpower. 

A  time-history  of  team  participation  is  graphed  in  Figure  9.  Multidisciplinary 
interaction  required  by  the  design  is  reflected  in  a  similar  graph  of  participation  by  technical 
discipline  in  Figure  10. 

BudfiSi- 

Just  over  $18,000  was  eventually  gathered  from  various  university  and  industrial 
sources.  An  additional  $13.3K  in  donated  and  loaned  equipment  was  provided  the  design 
team  for  application  throughout  the  system  [Figure  11].  Equipment  loans  included  items 
both  intended  for  use  in  the  ultimately  fielded  system  and  for  testing/validation.  Only  those 
loaned  hardware  components  utilized  on  the  final  system  are  included  in  the  figure. 
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MEMBERS 


Figure  9  -  Team  Strength  vs.  Time 
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Figure  10  -  Student  Technical  Discipline  vs.  Time 
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Figure  11  -  Capital  and  Equipment  Resources  vs.  Time 


Not  adequately  recorded  was  the  contribution  by  various  electronics  companies,  in 
particular,  who  provided  component  samples  for  use  in  various  circuits  embedded  in  key 
components  throughout  the  system. 

Facilities- 

No  dedicated  facilities  were  made  available  until  December  1990,  when  office  space 
was  allocated  to  the  team.  In  January  1991,  mechanical  malfunction  allowed  the  group 
access  to  an  adjacent  bay  of  a  hover  test  facility.  This  area  served  as  the  team’s  ultimate 
focal  point  for  the  remainder  of  the  design  cycle. 

Electrical  engineering  students  working  on  other  research  were  able  to  use  lab  space 
allocated  them  to  work  on  the  aerial  robotics  design  effort. 
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A  final  area  was  provided  to  lay  out  a  scale  competition  arena  for  use  in 
testing/validating  the  proposed  vision  system  in  its  navigation  application. 

Test  flights,  for  the  most  part,  were  conducted  on  the  roof  of  Georgia  Tech's  student 
parking  garage. 

It  should  be  noted  that  integration  efforts  were  not  well  served  by  the  "patchwork" 
nature  of  available  facilities  [Figure  13]. 

Experience. 

None  of  the  team's  student  or  faculty  members  had  radio-control  (R/C)  helicopter 
experience.  Fortunately,  volunteer  participation  by  members  from  two  local  R/C  clubs 
overcame  this  difficulty. 
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Figure  12  -  Allocated  Floor  Space  vs.  Time 
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1"  =  approximately  .1  miles 

Figure  13  -  Aerial  Robotics  Facilities 
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However,  as  design  applications  arc  a  focus  of  both  undergraduate  and  graduate  programs 
in  most  engineering  schools  at  Georgia  Tech,  the  team  did  possess  considerable  knowledge 
of  the  design  process,  although  limited  experience  beyond  the  preliminary  design  stage. 

Whv  Were  Concurrent  Engineering  Techniques  Important  to  this  Project? 

In  order  to  counteract  effects  of  the  radically-shortened  design  cycle  presented  by 
the  AUVS  and  limited  budget,  techniques  to  reduce  development  time  and  achieve  higher 
quality  at  lower  cost  were  necessary.  These  principles  are  the  underlying  emphasis  of 
concurrent  engineering  application12. 

The  original  intent  of  the  Institute  for  Defense  Analyses  (IDA)  study  [1]  (Winner)  in 
evaluation  concurrent  engineering  applications  was  to  prove  or  disprove  the  claim  of 
shortened  design  cycles  resulting  in  higher  quality  products  with  lower  life  cycle  costs. 
Winner's  report  documents  several  examples  of  proven  application  of  CE  principles 
throughout  industry.  More  recently: 

-  Development  of  an  integrated  computer-aided  design  (CAD)  and  manufacturing 
environment  (CAM)  at  Lockheed  during  their  recent  successful  Advanced  Tactical  Fighter 
(ATF)  bid,  resulted  in  fewer  than  200  engineering  design  changes  being  required  during 
assembly  of  the  first  aircraft  [6]. 

-  Simulation  applications  by  the  U.S.  Army  Tank-Automotive  Command  (TACOM) 
Research  Development,  and  Engineering  Center  resulted  in:  (1)  improved  product 
performance  through  the  ability  to  investigate  a  variety  of  design  alternatives  prior  to  the 


12.  Daniel  P.  Schrage,  "Preliminary  Design  of  a  Light  Commercial  Utility 
Helicopter",  Concurrent  Design:  A  Case  Study,  p.  8. 
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prototype  stage,  (2)  reduced  design  and  manufacturing  costs  through  identifying  and 
solving  mechanical  problems  during  the  design  phase,  (3)  and  the  ability  to  select  a  more 
economical  design  alternative  with  equivalent  performance  [7]. 

If  the  documented  gains  through  application  of  concurrent  engineering  techniques 
were  not  enough,  Sobieski  [8]  argued  the  traditional  sequential  design  process  results  in 
suboptimality  in  design.  Given  that  resources,  as  described  in  the  previous  section,  are 
limited,  Sobieski  asserts  that  optimization  loops  on  the  sequential  design  process 
[Figure  14]  are  impossible.  This  suboptimality  results  in,  what  Sobieski  terms  as,  "the 
Paradox  of  Sequential  Design"  [Figure  15].  As  knowledge  about  the  design  increases,  the 
engineer's  ability  to  influence  the  design,  based  on  that  knowledge,  is  reduced. 

Schrage  and  Rogan  [9]  qualitatively  address  the  impact  of  concurrent  engineering's 
application  to  this  'paradox'.  Given  that  product  and  process  are  engineered  concurrently, 
greater  knowledge  is  available  earlier  in  the  design  cycle  when  design  freedom  is  still  high 
[Figure  16]. 

In  the  aerial  robotics  competition  context,  application  of  concurrent  engineering 
techniques,  documented  to  have  reduced  product  development  cycles  by  as  much  as  fifty 
(50)  percent13,  could  theoretically  result  in  'stretching'  the  robot’s  development  time  to 
over  514  design  days.  Fewer  design  changes  would  ultimately  result  in  lower  development 
cost,  desirable  given  the  product  was  initiated  with  an  uncertain  monetary  foundation. 


13.  Winner  et  al.,  p.  vi. 


13 


Interdisciplinary  Iterations 


Intradisciplinary  Iterations 


DISCIPLINES  AERODYNAMICS  STRUCTURES  AEROELASTICITY, 

etc. 


Figure  14  -  An  Example  of  the  Sequential  Design  Process14 


TIME  INTO  THE  DESIGN  PROCESS 
Figure  15  -  "The  Paradox  of  Sequential  Design"15 


14.  Jaroslaw  Sobieszczanski-Sobieski,  "Multidisciplinary  Optimization  for 
Engineering  Systems:  Achievements  and  Potential",  Lecture  Notes  in  Engineering. 

alS 


,  Bonn,  June  1989,  p.  43. 


15.  Ibid.,  p.  45. 


14 


Figure  16  -  Impact  of  Concurrent  Engineering  Application16 


*  NOTE:  Conceptual,  preliminary,  and  detailed,  as  noted  in  the  figures  above,  describe 
typical  periods  of  the  sequential  design  cycle. 


16.  Daniel  P.  Schrage  and  J.  Edward  Rogan,  "The  Impact  of  Concurrent 
Engineering  on  Aerospace  Systems  Design",  White  Paper.  School  of  Aerospace 
Engineering,  Georgia  Institute  of  Technology,  Atlanta,  Georgia,  p.  6. 
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CHAPTER  II 


HOW  WAS  CONCURRENT  ENGINEERING  TO  BE  IMPLEMENTED? 


Ten  Characteristics  Required  for  the  Successful  Implementation 
of  Concurrent  Engineering 


In  an  effort  to  capture  lessons  learned  by  various  companies,  the  Computer-Aided 
Acquisition  and  Logistics  Support  (CALS)/CE  Mechanical  Systems  Working  Group 
highlighted  ten  characteristics  identified  as  keys  to  successful  implementation  of  concurrent 
engineering  [5].  Schrage  [10]  further  modified  this  list  to  include  prerequisites  for  their 
implementation. 

The  Georgia  Tech  Aerial  Robotics  Design  Team  adopted  these  tenets  as  a  template 
for  their  group's  organization  and  design  policies  and  procedures.  A  discussion  of  how 
these  characteristics  were  to  be  put  into  practice  follows. 

A  Tod;Dqwh. Design.  Aimr.Qac.h_B ased  on  a  Comprehensive  Systems  Engineering  Process. 

Top-down  design  implies  an  evaluation  and  decomposition  of  the  perceived  design 
task  into  smaller  engineering  problems  and  is  a  common  design  method  across  several 
engineering  fields. 
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MIL-STD-499A  [11]  defined  systems  engineering  (SE),  in  the  Department  of 


Defense  (DoD)  context,  as: 


the  application  of  scientific  and  engineering  efforts  to  (a)  transform  an 
operational  need  into  a  description  of  system  performance  parameters  and  a 
system  configuration  through  the  use  of  an  iterative  process  of  definition, 
synthesis,  analysis,  design,  test,  and  evaluation;  (b)  integrate  related  technical 
parameters  and  ensure  compatibility  of  all  physical,  functional,  and  program 
interfaces  in  a  manner  that  optimizes  the  total  maintainability,  safety, 
survivability,  human,  and  other  such  factors  into  the  total  engineering  effort  to 
meet  cost,  schedule,  and  technical  performance  objectives17. 


Top-down  design,  on  its  own,  stands  the  chance  of  decomposing  the  problem  into  a 
myriad  of  specialty-specific  'sub-solutions'.  Systems  engineering  manages  these  to  ensure 
an  integrated  team  effort  to  meet  design  objectives  specified  in  the  SE  definition  itself. 

Successful  concurrent  engineering  requires  a  combination  of  both  participative  and 
authoritative  management18.  Participation  of  all  specialties  in  the  design  solution  is 
imperative  to  consensus  building  and  establishing  a  sense  of  ownership  about  the  design. 
In  some  cases  however,  specialty-specific  design  solutions  do  not  contain  the  appropriate 
global  perspective  and  require  authoritative  adjudication. 

Implementation  of  this  tenet  in  design  of  the  GT  aerial  robot  was  accomplished 
through  implementation  of  a  Work  Breakdown  Structure  (WBS)  and  development  of  a 
System  Engineering  Management  Plan  (SEMP). 

A  WBS  was  developed  to  component  level.  Responsibility  for  design  of  the 
system's  various  pieces  was  then  assigned  using  this  structure.  The  WBS  was  also  helpful 


17.  Defense  Systems  Management  College,  p.  1.2. 

18.  Daniel  P.  Schrage,  Concurrent  Design:  A  Case  Study,  p.  10. 
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in  identifying  specialties  not  represented  on  the  team  and  provided  a  'wish  list’  for 
prospective  team  members. 

The  SEMP  was  modeled  after  the  Joint  Project  Office's  (JPO)  Unmanned  Aerial 
Vehicle  (UAV)  System  Engineering  Management  Plan  [12]  issued  by  the  DoD.  A  common 
language  to  describe  system  components,  team  organization  and  responsibilities,  a 
projected  milestone  list,  and  team  management  philosophy  were  included. 

Electronic  correspondence,  utilizing  the  Georgia  Tech  campus  computer  system, 
was  implemented.  This  allowed  student  engineers  the  ability  to  communicate  rapidly  and 
securely  with  the  entire  team  through  use  of  the  subscriber  group  uav@pravda. 
Communication  between  individuals  could  be  accomplished  using  normal  e-mail 
procedures.  E-mail  was  deemed  particularly  important  given  the  multidisciplinary,  hence 
dispersed-about-campus  team.  It  further  served  as  a  historical  record,  through  default 
means,  of  the  design  process. 

Strops  Interface  with, .the.  Customer- 

Taguchi  defines  quality  as  "the  loss  a  product  causes  to  society  after  being  shipped, 
other  than  any  losses  caused  by  its  intrinsic  functions"19.  Understanding  what  society  (the 
customer)  wants,  therefore,  is  key. 

The  team  clearly  identified  the  customer  for  this  product  as  the  Association  for 
Unmanned  Vehicle  Systems  (AUVS)  with  the  competition  rules  and  updates  serving  as 
their  Request  for  Proposal  (RFP)  or  Product  Definition  Specification  (PDS).  Satisfying 
these  requirements  would  likely  result  in  a  quality,  and  ultimately  winning,  system. 
Customer  requirements  were  further  analyzed  through  Quality  Function  Deployment 


19.  Genichi  Taguchi,  "The  Evaluation  of  Quality",  p.  1. 
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(QFD)  tables.  This  study  was  the  focus  of  several  student  teams  in  a  Concurrent 
Engineering  project  accomplished  to  compliment  preliminary  system  design  by  Georgia 
Tech's  aerial  robotics  team. 

The  system  engineer  was  designated  primary  point  of  contact  for  the  team  with  the 
AUVS.  This  was  done  in  order  to  assure  all  questions  were  focused  through  a  single  voice 
and  that  answers  received  were  disseminated  to  the  entire  team. 

Multifunctional  and  Multidisciplinary  Teams. 

Schrage  describes  this  as  the  "characteristic  most  associated  with  concurrent 
engineering"20. 

As  already  discussed  in  outlining  the  team's  design  environment  and  in  describing 
work  responsibilities,  specialties  were  sought  which  would  contribute  to  the  system’s 
overall  design. 

Obvious  during  initial  organization  meetings  was  the  requirement  for  computer, 
electrical,  and  mechanical,  as  well  as  aerospace  engineers.  Ultimately,  students  from  these 
engineering  schools  and  the  School  of  Civil  Engineering  participated  on  the  design  team. 
Faculty  advisors,  as  diverse  in  technical  specialties,  complimented  the  student  contingent 
and  provided  expert  advice  in  application  of  various  technologies  to  the  system. 

Design  Benchmarking  and  Soft  Prototyping. 

Design  benchmarking  implies  continual  comparison  of  one  company's  competing 
design  to  another's.  This  provides  some  measure  of  design  quality,  but  used  alone,  can 
result  in  an  incrementally  better  system  to  another  competitor,  while  a  vastly  superior 
design  may  have  been  possible. 


20.  Daniel  P.  Schrage,  Concurrent  Design;  A  Case  Study,  p.  12. 
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Soft  prototyping  requires  the  development  of  a  digital  product  model21.  This 
results  in  tremendous  savings  of  both  time  and  funds,  as  described  in  the  example  of 
TACOM’s  simulation  successes. 

When  combined  with  benchmarking,  soft  prototyping  allows  comparison  of  digital 
prototypes  to  competitor  designs  without  huge  resource  expenditure.  Design  freedom  is 
thus  maintained  to  explore  other,  perhaps  better  options. 

Although  the  AUVS  did  not  distribute  details  on  competitor  progress  leading  up  to 
the  competition,  and  teams,  for  the  most  part,  elected  to  maintain  some  degree  of  secrecy 
about  their  designs,  benchmarking,  as  a  means  to  define  the  system's  configuration  at  a 
specific  point  in  the  design  cycle,  was  done.  The  team  published  a  Benchmark  1  report, 
describing  the  aerial  robot's  preliminary  design.  This  document  was  provided  to  the 
customer  and  the  team's  industrial  partners. 

Soft  prototyping  efforts  were  initiated  through  development  of  a  computer  solid 
model  of  the  system's  payload  and  through  computer-aided  design  (CAD)  application  to 
magnetic  array  layout  The  solid  model's  database  ultimately  provided  required  dimensions 
for  the  forward  payload  shelf,  several  universal  joint  (u-joint)  components,  electrical 
connections,  and  greatly  assisted  with  weight  and  balance  efforts.  CAD  application  to  the 
magnetic  array  resulted  in  a  geometrically  optimized  layout  and  reduced  the  originally 
suggested  magnet  number  by  33%  with  no  performance  penalty. 

Simulation  of  Product  Performance  and  Manufacturing  and  Support  Processes. 

The  team  envisioned  applying  several  widely-used  computer  design  tools.  As 
examples,  ARMCOP,  a  stability  and  control  simulation  package  developed  by  NASA,  was 
to  evaluate  stability  and  control  characteristics  of  the  aerial 


21.  Daniel  P.  Schrage,  Concurrent  Design:  A  Case  Study,  p.  13. 
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vehicle  under  different  weight  and  balance  configurations.  Various  commercially-available 
digital  circuit  board  simulation  and  layout  tools  were  readily  available. 

The  design  team  was  unaware  of  any  tools  available  at  Georgia  Tech  which  could 
simulate  the  manufacturing  or  support  processes,  although  such  tools  exist.  As  an 
example,  as  part  of  its  Integrated  Product  Development  (IPD)  initiatives,  General  Dynamics 
Fort  Worth  developed  COMOK  (Computerized  Mock-Up)  which,  when  coupled  with  the 
"electronic  crew-chief,  allowed  engineers  the  ability  to  study  maintainability  issues 
through  simulation,  eliminating  the  need  for  hard  mock-ups  [13]. 

Early  Involvement  of  Subcontractors  and  Vendors. 

During  the  system's  conceptual  design  phase,  the  team  hosted  an  overview  for 
interested  representatives  from  industry.  From  this  point,  and  continuing  throughout  the 
design  cycle,  periodic  site  visits  by  off-campus  team  participants  kept  everyone  aware  of 
the  system's  progress,  as  well  as  providing  necessary  feedback.  As  already  mentioned,  the 
Benchmark  1  report  was  provided  all  team  participants  and  equipment  donors  as  a  means  of 
keeping  communications  with  team  supporters  open. 

Although  the  number  of  vendors  providing  components  to  Tech's  aerial  robot  was 
significantly  less  than  with  commercially-produced  aircraft  systems,  it  was  felt  that 
common  agreement  on  scheduling  objectives  through  adoption  of  an  integrated  schedule 
might  alleviate  integration  conflicts  downstream. 

Results  of  the  team's  partnership  efforts  have  resulted  in  relationships  extending 
into  the  next  design  phase. 

Continuity  of  the  Teams. 

The  team,  in  its  preliminary  effort,  could  not  hope  to  accomplish  this  longer-term 
objective.  However,  some  attention  was  devoted  to  ensuring  a  balance  of  undergraduate 
and  graduate  student  participation  in  order  to  maintain  a  team  over  the  next  several  years. 


21 


The  team's  initial  goals  were  simply  to  design  and  develop  a  baseline  system. 
Should  time  be  available,  within  the  constrained  design  cycle  and,  after  successful 
demonstration  of  this  system  accomplishing  the  AUVS  mission,  product  optimization  could 
be  attempted.  Process  optimization,  like  team  continuity,  was  something  to  be  addressed 
after  progression  through  at  least  one  complete  design  cycle. 

Optimization  focus,  should  the  team  progress  that  far,  was  addressed  to  a  limited 
extent  in  the  integrated  schedule  and  the  Benchmark  1  report. 

Experiments  to  Confirm/Change  High  Risk  Predictions  Found  Through  Simulation. 

Simulation  efforts  were  limited  during  this  initial  phase  due,  primarily,  to  time 
necessary  to  set  up  an  appropriate  simulation  environment.  In  addition,  quality  engineering 
experiments  typically  rely  on  historical  stati  deal  information  on  which  to  base  engineering 
experiments.  This  type  data  was  simply  not  available  due  to  the  uniqueness  presented  by 
design  of  a  system  on  this  scale. 

The  tenth  characteristic  of  successful  CE  implementation,  Corporate  Focus  on 
Continuous  Improvement  and  Lessons  Learned,  has  been  deferred  more  appropriately  to 
the  Analysis  of  Results  and  Conclusions  sections  of  this  report.  It  was,  however, 
recognized  that  documentation  would  serve  a  significant  function  in  eventual  team  success, 
either  during  the  first,  or  a  successive,  competition.  To  that  end,  files  of  meeting  ager.das, 
design  discussion,  expenditures,  and  other  relevant  information  were  kept.  The 
completeness  of  this  thesis,  and  other  post-Phase  I  documents,  is  ultimately  a  measure  of 
the  team's  attention  to  record-keeping  while  the  team's  competition  performance  over  time 
will  serve  as  an  adequate  metric  of  success  in  applying  this  tenet  of  concurrent  engineering. 
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CHAPTER  III 


THE  AERIAL  ROBOT  DESIGN  CYCLE 


Overview 


Work  to  develop  the  Georgia  Tech  aerial  robot  was,  except  for  the  period 
immediately  preceding  the  competition,  accomplished  in  three  month  blocks.  Four  discrete 
time  elements,  coinciding  with  the  quarter  class  schedule  and  comprising  the  design  cycle, 
are  presented  here. 


Block  1 

August  -  December  1990 

Block  2 

January  -  March  1991 

Block  3 

April  -  June  1991 

Block  4 

June  -  July  1991 

Presentation  in  each  block  will  attempt  to  overview  the  design  environment  by 
reviewing  significant  changes  in  team  resources,  listing  cumulative  assumptions  bearing  on 
the  problem  which  have  not  been  eliminated  through  hardware  selection  or  component 
testing,  highlighting  important  information  gained  about  the  design,  and,  where 
appropriate,  outlining  design  objectives  for  the  period.  Work  accomplished  will  be 
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reviewed,  including  quality  engineering  tools  and  concurrent/systems  engineering  concepts 
which  supported  design  decisions.  Finally,  a  brief  recap  of  the  project's  status  at  the  close 
of  each  time  phase  will  be  given. 


Block  1  (August  to  December  19901 
Establishing  the  Design  Environment.  Problem  Definition,  and 
Aerial  Vehicle  Selection 


The  Beginning. 

A  joint  meeting  between  interested  students  and  faculty  and  the  Association  for 
Unmanned  Vehicle  Systems  (AUVS)  was  held  in  late- August  in  the  School  of  Aerospace 
Engineering.  Interested  faculty  in  attendance  included  professors  from  the  Schools  of 
Aerospace  and  Civil  Engineering.  The  AUVS  was  represented  by  Mr.  Robert  C. 
Michelson,  First  Vice-President  and  author  of  the  First  International  Aerial  Robotics 
Competition.  The  primary  focus  of  this  gathering  was  to  review  proposed  rules  for  the 
competition  and  to  discuss  formation  of  a  Georgia  Tech  team. 

This  working  group  determined  the  competition  would  provide  a  unique 
opportunity  to  field  a  multidiscipinary  design  team.  Academic  courses  were  envisioned  to 
compliment  required  design  tasks,  and  formulation  of  the  design  as  a  concurrent 
engineering  pilot  project,  which  Winner  had  found  useful  in  demonstrating  CE  benefits22, 
began. 

Funding  was  presented  as  a  key  issue.  Similar  hardware-oriented  engineering 
competitions  had  proven  extremely  expensive  in  the  past. 

Finally,  the  group  recognized  the  challenge  presented  by  a  July  1991  competition 
date.  The  system's  underlying  assumption,  that  insufficient  time  was  available  in  which  to 


22.  Winner  et  al.,  p.  48. 
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design  an  aerial  vehicle  and  that  a  commercialfy-available  system  should  be  procured,  was 
made  at  this  initial  meeting. 

Organizing  the  Team  using  a  Work  Breakdown  Structure. 

Throughout  the  remainder  of  the  Block  1,  a  series  of  team  'recruitment'  meetings 
were  held.  Invitations  were  made  to  faculty  and  staff  members  in  the  Schools  of 
Aerospace,  Civil,  Mechanical,  and  Electrical;  the  College  of  Computing;  and  the  Georgia 
Tech  Research  Institute  (GTRI).  In  particular,  individuals  with  demonstrated  expertise  in 
autonomous  robotics,  control  system  engineering,  sensor  engineering  and  manufacture, 
and  design  were  invited  to  these  preliminary  meetings.  It  was  felt  that  research  already 
underway  by  each  of  these  professors  and  their  graduate  students  might  be  of  assistance  to, 
and  simultaneously  enhanced  by,  work  on  this  project. 

The  first  of  these  meetings  was  held  on  September  28th.  During  this  meeting.  Dr. 
Daniel  Schrage  presented  an  overview  of  a  long-term  concurrent  engineering  pilot  project  to 
be  centered  around  development  of  the  autonomous  aerial  robot.  Phase  I  was  organized  to 
focus  on  development  of  the  robot  for  the  AUVS  competition- specific  function.  A  follow- 
on  phase,  to  be  accomplished  after  successful  performance  in  the  Aerial  Robotics 
Competition,  was  to  conduct  detailed  research  on  specific  components,  technologies,  and 
methodologies  which  might  be  served  by  the  aerial  vehicle  as  a  test  bed.  Attendees 
included  students  from  aerospace,  electrical,  and  computing  backgrounds. 

The  'team'  was  directed  to  develop  a  Work  Breakdown  Structure  (WBS)  to  Level 
4.  This  would  help  assign  responsibility  within  the  system,  as  well  as  to  evaluate  technical 
specialties  needed,  but  not  yet  available  within  the  group.  A  WBS  presented  in  the  UAV 
SEMP  drafted  for  the  JPO  was  to  be  used  as  a  model. 
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A  hierarchical  decomposition  of  "hardware,  software,  services,  and  data  which 
completely  defines  the  problem"23,  the  WBS  is  essential  to  identifying  the  product  to  be 
engineered  and  relates  elements  to  one  another  and  the  system. 

Communication.  In  addition  to  WBS-development  efforts,  students  discussed 
methods  to  enhance  communication  between  design  team  members.  A  computer  bulletin 
board,  with  a  database  of  parameters  describing  each  hardware  component,  was  debated. 
The  intent  of  this  tool  was  to  allow  any  student  immediate  access  to  all  technical  data 
involved  with  the  design.  With  this  continuous  update,  evaluation  of  changing  parameters 
and  their  effects  on  the  design  and  manufacture  of  other  subsystems  could  be  identified, 
then  addressed  through  communication  on  the  more  traditional  e-mail  network. 
Implementation  required  each  subsystem  to  develop  a  list  of  technical  information  which 
would  describe  that  component  in  words. 

While  an  e-mail  subscriber  group  was  eventually  established,  the  bulletin  board,  as 
described  here,  was  never  accomplished  despite  renewed  efforts  during  Block  2.  Use  of 
the  e-mail  subscriber  group,  however,  did  allow  communication  between  any  member  of 
the  design  team  and  another,  bypassing  more  rigid  lines  of  coordination  that  sometimes 
stall  idea  exchange. 

On  October  12th,  the  first  scheduled  bi-weekly  working  group  meeting  was  held. 
Faculty  from  the  School  of  Electrical  Engineering  and  the  College  of  Computing  joined  the 
effort.  The  initial  WBS  was  presented  [Figure  17].  Responsibility  for  development  of 
each  subsystem  was  divided  among  the  represented  engineering  schools  and  colleges.  An 
attempt  was  made  to  align  perceived  technical  requirements  of  the  subsystem,  as  described 
by  the  WBS,  to  school-specific  engineering  specialties.  Aerial  vehicle  development  was, 


23.  Defense  Systems  Management  College,  p.  9.1. 
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therefore,  assigned  to  the  aerospace  school  and  development  of  the  mission  planning  and 
control  station  (ground  control),  given  to  the  College  of  Computing. 

Nomenclature  common  to  the  UAV  SEMP  was  selected  to  describe  the  subsystems. 
As  industrial  partners  were  soon  to  be  pursued,  and  the  DoD  had  been  involved  with 
industry  for  several  years  using  these  terms,  use  by  the  Georgia  Tech  team  was  seen  as  a 
way  to  enhance  communication  with  prospective  supporters. 

In  order  that  each  subsystem  group  understand  their  design  requirements,  draft  of  a 
team  SEMP,  similar  to  the  DoD  document,  was  required. 

Given  the  absence  of  such  a  document,  team  members  began  market  studies  of 
hardware  components  applicable  to  the  project.  In  addition,  'excess’  school  equipment 
was  identified  for  use  in  an  effort  to  further  reduce  the  effort's  cost.  Market  studies  of 
available  aerial  vehicles,  microprocessors,  and  communication  components  were  initiated. 

'Brainstorming'  sessions  attempted  to  evaluate  vehicle  alternatives  and  system 
sensor  requirements.  Although  subsystem  design  'boundaries'  had  already  been 
established,  this  relatively  'unfocused'  activity  ensured  the  system  captured  the  combined 
experience  offered  by  the  multidisciplinary  team. 

Aerial  Vehicle  Market  Evaluations- 

Until  payload  weight  and  volume,  achievable  on  an  aerial  vehicle  of  the  size  dictated 
by  the  competition,  was  fully  understood,  market  evaluations  and  brainstorming  sessions 
could  not  narrow  focus  to  discussion  of  feasible  hardware  and  methodology  alternatives. 
In  fact,  Pugh  [14]  presented  references  which  indicate  that  when  random  brainstorming  is 
accomplished,  it  is  of  little  utility.  "...The  more  specific  the  context,  the  more  prolific  and 
useful  the  solutions"24.  With  this  in  mind,  the  aerial  vehicle  group  initiated  a  detailed 
market  study  of  commercially-advertised  systems  in  mid-October. 
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While  over  twenty  helicopter,  ducted-fan,  and  co-axial  vertical  takeoff  and  landing 
(VTOL)  aircraft  were  actively  being  marketed,  only  a  handful  of  these  designs  had 
progressed  beyond  the  prototype  stage. 

Competition  rules  restricted  arena  access  to  two  team  members.  Therefore,  a 
system  capable  of  being  lifted  and  carried  by  two  men  was  adopted  as  an  informal  gross 
weight  limit.  It  should  be  noted  here  that  selection  of  one  particular  system  from  those 
surveyed  was  not  the  goal  of  this  exercise.  On  the  contrary,  only  a  reasonable  guess  as  to 
how  much  payload  weight  may  be  offered  by  a  given  sized  aerial  vehicle  was  the  analysis' 
objective. 

Given  the  data  available,  it  was  estimated  that  a  minimum  of  twenty-five  pounds  of 
useful  load  (fuel  and  payload)  might  be  offered  by  a  100-pound  aircraft  [Figure  18]. 
Twenty-five  pounds  was  considered  more  than  adequate  by  computer  and  electrical 
engineers  then  involved  with  the  project. 

A  Block  1  goal  of  aerial  vehicle  selection  was  established. 

The  maturity  of  ML  Aviation's  co-axial  Sprite  and  usable  weight  fraction  of  thirty 
(30)  percent,  made  it  an  attractive  option.  ML  Aviation  was  approached,  but  felt  their 
overseas  location  (Great  Britain)  made  affiliation  with  a  United  States  team  impractical. 

As  the  competition  mission  profile  only  required  flight  at  very  low  airspeeds  and 
significant  hover  times,  a  VTOL  configuration  with  high  hover  efficiency  (high  thrust  with 
low  disk  loading)  [Figure  19]  was  desired.  With  the  best  co-axial  option  gone,  a  more 
focused  effort  toward  identification  of  a  feasible  helicopter  design  was  begun. 


24.  Stuart  Pugh,  Total  Design:  Integrated  Methods  for  Successful  Product 
Engineering,  Addison-Wesley  Publishing  Company,  Wokingham,  England,  1990,  p.  90. 


29 


Figure  19  -  Hover  Efficiency  of  Various  VTOL  Configurations 


Industrial  Sponsorship. 

Concurrent  with  evaluations  of  candidate  hardware  was  the  effort  to  identify 
potential  team  sponsors.  It  was  hoped  that  through  solicitations  to  companies  already 
involved  in  the  unmanned  aerial  vehicle  market,  both  hardware  and  expertise  might  be 
offered  the  team  through  partnership. 

Over  sixty  corporations,  business,  laboratories,  and  individuals  were  notified  of  the 
effort  at  Tech  and  asked  to  respond  by  November  9th  to  an  invitation  to  be  briefed  on  the 
team's  progress  in  Atlanta.  Key  invitees  were  those  the  team  perceived  to  have  high-dollar 
hardware  components  applicable  to  development  of  this  system. 

Representatives  from  Boeing  Helicopter,  Rockwell,  United  Technologies,  the 
United  States  Army  Aerostructures  Directorate,  and  Signal  Tree  Research  attended  a  day- 
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long  conference  on  November  15th.  Of  the  five  organizations  represented,  only  the  Army 
Aerostructures  Directorate  would  ultimately  team  with  Georgia  Tech. 

Team  Growth  Continues.  Continued  recruitment  through  electronic  bulletin  board 
announcements  and  personal  invitations  resulted  in  increased  student  participation  by 
computer  and  civil  engineers.  Although  involved  in  many  of  the  early  organizational 
meetings,  the  civil  engineering  contingent  was  formally  assigned  responsibility  for  data  link 
development  in  early  November. 

The  System  Engineering  Management  Plan,  (SEMPj. 

A  SEMP  [14]  covering  the  Tech  team's  efforts  was  published  in  mid-October  and 
distributed  to  the  team  on  November  9th.  The  document  outlined  organization  of  the  team, 
management  philosophy,  responsibilities  for  work  within  the  system,  a  proposed 
schedule/milestone  list,  and  description  of  system  components.  Key  in  this  document  were 
definition  of  various  terms  used  by  the  team  in  describing  system  pieces. 

The  SEMP  established  the  following  design  objectives: 

(1)  by  the  end  of  Winter  quarter  1991,  to  have  identified,  purchased,  and 
completed  component-specific  engineering  necessary  to  begin  integration. 

(2)  during  Spring  quarter  1991,  to  integrate  the  subsystems  into  a  working 

system. 

(3)  during  Summer  quarter  1991,  to  accomplish  detailed  testing  and,  where 
appropriate,  optimization  of  the  system. 

In  general,  the  System  Engineering  Management  Plan's  "principle  role  is  in 
identifying  and  assuring  the  control  of  the  overall  engineering  process"25.  It  was  hoped  the 
Tech  document  would  adequately  serve  a  similar  purpose. 


25.  Defense  Systems  Management  College,  p.  3.1. 
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By  mid-November,  aerial  vehicle  options  had  narrowed  to  two  competing 
helicopter  designs,  although  both  exceeded  the  six  foot  size  restriction  imposed  by 
competition  rules. 

Conversations  with  both  aircraft  manufacturers  highlighted  Pacific  RPV's  ability  to 
modify  their  existing  Bruiser  airframe  to  meet  size  constraints.  Further,  this  aircraft  was 
being  procured  by  the  United  States  Army  Aerostructures  Directorate  for  use  in  their  Free- 
Flight  Rotorcraft  Research  Vehicle  (FFRRV)  project  [15].  In  addition,  the  Naval 
Postgraduate  School  had  utilized  two  of  these  aircraft  in  research  accomplished  there. 
Similar  hardware  capabilities  as  these  two  research  institutions  was  an  attractive  long-term 
feature  of  the  Bruiser's  selection. 

A  modified  Bruiser  II  aircraft  [Figure  20]  was  ordered  on  November  19th. 
Manufacture  was  anticipated  to  take  approximately  three  weeks  with  delivery  to  the  Tech 
team  to  take  place  shortly  after  classes  began  in  January  1991. 

A  stability  augmentation  system  (SAS),  developed  for  one  of  Pacific's  larger 
model  aircraft,  was  also  applicable  to  the  Bruiser  and  was  configured  to  interface  readily 
with  available  hobby  control  systems.  Algorithms  developed  for  the  SAS  were  advertised 
to  be  "readily  ported  to  a  larger,  more  sophisticated  control  system  that  incorporates  auto¬ 
pilot  functions  and  autonomous  operations".  Although  not  initially  purchased,  further 
evaluation  of  the  SAS,  seemed  warranted. 

In  addition,  Pacific  agreed  to  provide  the  team  a  .60  series  GMP  Competitor  to  be 
used  as  a  flight  trainer. 

BtafiU.-Wiap.Up. 

A  final  Fall  quarter  meeting  was  conducted  on  December  4th. 
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Team  Contact  with  Local  Radio-Control  Modelers.  Due  primarily  to  selection  of 
the  Bruiser  as  the  team's  aerial  vehicle,  contact  was  established  with  several  local  radio¬ 
control  (R/C)  modelers.  Two  members  of  the  Cobb  County  Radio-Control  Club  (CCRC), 
attended  this  December  4th  meeting. 

The  team's  intent  was  to  utilize  these  experienced  modelers  to  help  train  one  or 
more  student  pilots.  A  by-product  of  this  contact  was  an  extremely  rapid  learning  curve 
progression  through  key  R/C  operation  and  maintainability  issues.  This  relationship  would 
prove  crucial  in  the  coming  months. 


Figure  20  -  Pacific  RPV's  Bruiser 
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Student  Participation.  At  the  Fall  quarter's  conclusion,  only  the  aerial  vehicle, 
mission  planning  and  control  station  (MPCS),  and  data  link  were  'covered'  by  student 
leaders.  Although  two  faculty  members  of  the  electrical  engineering  school  had  participated 
throughout  the  quarter,  only  one  student  had  become  involved,  leaving  significant  work  to 
be  done  in  design  and  manufacture  of  the  disk  retrieval  system. 

Less  significant,  due  to  the  status  of  procured  hardware,  but  no  less  important,  was 
a  manpower  void  in  the  system’s  logistics  support  structure.  Arrival  of  the  Bruiser  would 
necessarily  require  growing  attention  to  maintenance  and  other  logistics  issues. 

Faculty  Participation.  All  major  subsystem  groups,  less  the  logistics  support 
subsystem,  were  supervised  by  team  faculty  advisors  at  the  conclusion  of  the  Fall  quarter. 
Even  with  the  already  large  faculty  contingent,  no  mechanical  engineering  professors  were 
yet  involved  with  the  team. 

Industry  Partners.  In  addition  to  Pacific  RPV,  Incorporated,  Guided  Systems 
Technologies  (GST),  a  small  company  located  in  Georgia  Tech’s  Advanced  Technology 
Development  Center  (ATDC),  had  become  involved.  With  particular  expertise  in  control 
system  design,  it  was  hoped  GST  could  assist  the  team  in  design  of  their  autonomous  flight 
control  system. 

In  a  conference  call  with  Pacific  RPV  following  this  final  meeting,  discussions  of 
vehicle  stability  yielded  projected  attitude  hold  within  .1  degree  and  heading  to  within  1 
degree.  Further  evaluation  of  the  costs  involved  in  procuring  one  of  Pacific's  stability 
augmentation  systems  resulted  in  an  expected  $1200  to  $1300  expenditure  were  the  boards 
laid  out  at  Pacific  and  manufactured  at  Georgia  Tech,  a  substantial  cost  savings  to  the  team. 
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Knowledge  About  the  Design- 
Assumptions. 


(1)  The  underlying  assumption  for  development  of  the  entire  system  was  the 
evaluation  that  insufficient  time  would  be  available  to  manufacture  an  aerial  vehicle  'in- 
house'. 

(2)  Any  discussion  of  computer  vision  as  applied  to  development  of  this  system 
centered  around  application  of  the  Dickerson  integrated  vision  system  (IVS).  Details  of  the 
system  are  provided  at  Appendix  A. 

(3)  The  team  felt  that  retrieving  six  disks  was  an  attainable  goal. 

Competition  Rules.  Nearly  three  months  of  evaluation  resulted  in  a  clear  picture  of 

the  competition's  requirements.  Where  uncertainties  existed,  proximity  of  the  team  to  the 
event's  author  resulted  in  rapid  resolution. 

System  Hardware.  While  the  aerial  vehicle  had  been  selected,  only  scant  marketing 
data  and  information  gained  from  telephone  conversations  with  the  aircraft’s  manufacturer 
were  available.  Final  aircraft  dimensions  were  still  to  be  determined  during  manufacture. 

Other  Bruisers  had  been  shown  to  lift  approximately  eighteen  (18)  pounds  of 
payload. 

System  Software.  Although  a  very  preliminary  effort,  top-down  decomposition  of 
required  mission  planning  and  control  tasks  was  accomplished.  Key  system  issues 
regarding  power  up  and  component  initialization  procedures  began  to  be  addressed. 

Pcsign  Freedom- 

In  the  context  of  this  thesis,  available  design  freedom  was  viewed  as  unspent  capital 
resources.  Therefore,  purchase  of  the  Bruiser  aircraft  resulted  in  a  loss  of  approximately 
35%  of  the  team's  freedom  about  the  design.  A  more  detailed  evaluation  of  this  trend  is 
offered  in  the  Analysis  of  Results. 
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Aerial  Robot  Design  Cycle:  Block  1 

l»  September  I  October  I  Novemhtj 


a 


■V  Working  Group  Meeting 


q  »  Bruiser  Selected  as  Aerial  Vehicle 
^  JQ  Team  Briefing  to  Industry 

Os  1  System  Engineering  Management  Plan  1 


Working  Group  Meeting  _  _ 

IWork  Breakdown  Structure  Developed  I 


First  Team  Organization  Meeting 


Initial  Meeting  with  AUVS 


Figure  21  -  Key  Block  1  Design/Organization  Events 
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Block  2  (January  to  March  1991) 

Refining  the  Design  Environment  and  System  Definition 


Design  Environment  Overview. 

Time.  Roughly  sixty  percent  of  the  available  design  cycle  (206  days)  remained 
with  commencement  of  classes  in  early  January. 

Continued  Student  Recruitment.  With  delivery  of  the  aerial  vehicle  pending,  and 
receipt  of  additional  funds  to  support  the  project,  concerted  efforts  were  initiated  to  round 
out  the  student  design  team  contingent. 

With  the  assistance  of  the  CCRC,  an  R/C  helicopter  demonstration  was  scheduled 
adjacent  to  the  Student  Center  on  January  4th  in  order  to  attract  attention  to  the  competition 
and  Georgia  Tech's  efforts.  In  particular,  electrical  and  mechanical  engineering  students 
were  sought  to  assist  with  key  disk  retrieval  and  vision  issues.  High  winds,  however, 
forced  cancellation  of  the  event. 

A  final  organized  appeal  for  support  was  made  four  days  after  receipt  of  the  Bruiser 
on  January  7th.  Mr.  John  Smith  of  Pacific  RPV,  principle  aircraft  designer  and 
manufacturer,  visited  Georgia  Tech  in  order  to  personally  hand  off  the  aircraft  and  address 
team  questions.  His  comments  attracted  a  large  student  audience  as  he  described  the 
Bruiser's  development  and  current  commercial  applications.  This  gathering,  and  the 
supporting  curriculum  to  be  described,  resulted  in  student  participation  reaching  a  peak  of 
near  twenty-five  (25)  graduate  and  undergraduate  engineers. 

Supporting  Academic  Coursework.  In  addition  to  direct  recruitment  efforts,  several 
courses,  taught  by  faculty  involved  in  the  aerial  robotics  effort,  addressed  system  issues 
through  application  of  course  projects  to  the  design.  This  type  support,  unique  to  an 
academic  environment,  while  not  directly  providing  manpower  resources  to  the  system's 
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design,  was  a  useful  tool  in  leveraging  team  manpower  to  more  mainstream  design 
alternatives. 

A  concurrent  engineering  course,  utilizing  the  aerial  robotics  design  effort  as  a 
project  focus,  further  analyzed  the  competition  requirements  and  sought  to  establish  a 
preliminary  design  through  detailed  system  synthesis  using  quality  and  system  engineering 
techniques. 

Electrical  engineering  coursework  on  the  manufacture  of  sensors  and  transducers 
led  directly  to  development  of  the  system's  altimeter  and  object  retrieval  mechanism. 

Evaluation  of  the  vehicle's  stability  and  control  characteristics  was  accomplished  as 
the  quarter  project  by  a  helicopter  stability  and  control  course. 

Finally,  a  myriad  of  special  topics  and  problems  addressed  a  variety  of  system 
issues  beginning  in  the  Winter  quarter  1991,  and  continuing  through  the  competition's 
completion.  For  example,  two  electrical  engineering  design  problems  addressed  an 
autonomous  ground  robot  as  an  alternative  to  development  of  a  vehicle-nested  retriever. 

Faculty  Involvement.  All  discussion  of  computer  vision  as  applied  to  this  design 
had  centered  around  use  of  a  lightweight  integrated  vision  system  developed  by  Dr.  Steve 
Dickerson  in  the  School  of  Mechanical  Engineering.  His  formal  involvement,  beginning  in 
early  January,  would  serve  the  team  as  a  needed  information  resource  as  the  camera 
matured  in  both  hardware  and  computer-code  toward  specific  application  in  this  context. 

Industrial/Government  Participation.  In  early  February,  the  Aerostructures 
Directorate  formally  joined  the  team.  Their  expertise  with  data  link  options  and  electronic 
component  development  would  prove  crucial  in  the  final  weeks  leading  to  the  competition. 

Community  Interaction.  The  team  made  a  formal  presentation  to  the  CCRC  on 
January  21st.  This  meeting  produced  a  machinist  volunteer  and  resulted  in  a  discount 
being  offered  the  team  to  purchase  R/C  supplies  at  a  local  hobby  shop. 
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Budget.  Significant  funding  through  joint  research  seed  monies  was  received  in 
early  January.  This,  and  the  grant  already  obtained  through  the  Office  of  Interdisciplinary 
Research  in  mid-November,  represented  96.7%  of  the  capital  available  for  system 
development.  A  final  request  to  the  Georgia  Tech  Student  Foundation  on  February  17th 
was  not  granted  as  they  perceived  the  aerial  robotics  effort  capable  of  attracting  sufficient 
outside  resources. 

Facilities.  An  additional  bay  in  Room  103  of  the  Montgomery  Knight  building  was 
obtained  in  early-January. 

Initial  Executive  Committee  OEXCOM)  Meeting. 

Work  during  the  Winter  quarter  began  with  receipt  of  the  Bruiser  aircraft  on 
January  7th.  Assembly  was  quickly  accomplished,  but  no  further  evaluation  was 
conducted,  pending  a  visit  by  the  aircraft's  manufacturer  later  that  week. 

The  EXCOM,  as  defined  in  the  SEMP,  met  for  the  first  time  officially  on  January 
9th.  The  following  team  and  design  issues  were  discussed  at  that  meeting: 

Team  Reorganization.  Perceived  'excess'  team  members  in  the  aerial  vehicle  group 
were  reassigned  responsibility  for  the  integrated  logistics  support  subsystem.  As  the 
aircraft  would  quickly  represent  the  thrust  of  that  effort,  use  of  an  aerospace  engineer  to  fill 
this  team  void  seemed  logical.  No  technical  expertise  was,  however,  available  in  any  of  the 
subsystems  which  would  allow  development  of  a  retriever  to  be  initiated.  Therefore, 
openings  were  still  recognized  in  the  mission  equipment  package  and,  because  of  only  three 
undergraduate  students  participating,  the  data  link  subsystems. 

A  vision  group,  led  by  students  from  the  College  of  Computing,  was  formed  to 
address  hardware  and  software  development  of  the  Dickerson  camera.  At  this  stage,  only 
one  camera  was  to  be  used  to  perform  both  the  navigation  and  target  detection  functions.  It 
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was  hoped  the  'switching'  problem  between  function-specific  optics  and  algorithms  would 
be  solved  by  this  group. 

Flight  Training  to  Commence.  A  volunteer  from  the  CCRC  agreed  to  offer  a 
ground  school  to  students  interested  in  learning  how  to  fly  R/C  helicopters.  A 
commercially-available  flight  simulation  package  was  loaned,  and  another  purchased  for 
use  at  Tech. 

Aircraft  Test  Scheduling.  As  team  focus  centered  on  gathering  as  much  technical 
information  about  the  aircraft  as  quickly  as  possible,  scheduling  issues  needed  to  be 
addressed.  The  aerial  vehicle  group  was  directed  to  develop  a  test  schedule  with  input  from 
the  other  subsystems. 

Payload  Areas.  Two  payload  areas  were  obvious,  one  forward  of  the  firewall  and 
another  underneath  the  keel  plate  between  the  landing  gear  [Figure  22].  It  was  decided  the 
forward  area  would  be  reserved  for  all  hardware  associated  with  the  data  link,  guidance 
system,  and  flight  control  computers. 

The  lower  payload  area  was  designated  for  use  by  the  mission  equipment  package 
(MEP).  As  the  retriever  was  anticipated  to  be  one  of  the  heavier  payload  components,  its 
placement  as  close  to  the  main  rotor  mast  as  possible  was  critical.  In  addition,  desired 
'placement'  of  the  longitudinal  center  of  gravity  could  then  be  accomplished  through  subtle 
displacement  of  the  retriever  along  the  vehicle  x-axis. 
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Payload  Area  #2 

Stability  Augmentation  System 
Onboard  Downlink  Components  I 


Payload  Area  #1 

Vision  Sensors 
Retrieval  Mechanism 


Figure  22  -  Designated  Payload  Areas 


A  preliminary  design  freeze,  anticipated  at  the  end  of  work  for  the  Winter  quarter, 
was  hoped  to  identify  volume  and  weight  issues  associated  with  payload  layout.  Some 
modifications  to  the  existing  landing  gear  (addition  of  a  payload  shelf)  and  forward  payload 
fairing  (increase  volume)  were  envisioned. 

Assumptions.  It  was  recognized  that  design  work  being  accomplished  in  the 
various  courses  already  mentioned  needed  some  technical  constraints.  Therefore,  the 
system  engineer  presented  a  series  of  assumptions  about  the  design  which  he  hoped  would 
further  focus  conceptual  and  preliminary  design  efforts. 

(1)  Vehicle  dynamics  were  considered  too  fast  for  data  link  to  ground-based 
computers  for  control.  This  assumption  was  made  after  several  telephone  conversations 
with  the  aircraft  manufacturer  and  analysis  of  the  system’s  vulnerability  through  use  of 
offboard  computing  power.  The  impact  of  this  assumption  was  that  computational 
capability  necessary  to  stabilize  the  aircraft  must  be  onboard. 
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(2)  The  aerial  vehicle  was  assumed  capable  of  holding  position  to  plus  or  minus 
three  inches  (3")  in  altitude,  plus  or  minus  two  degrees  (2°)  in  heading,  and  maintaining  a 
stable  hover  over  a  one  foot  (T)  diameter  circle  on  a  calm  day.  Again,  the  heading  and 
altitude  assumptions  were  made  after  conversations  with  Pacific  RPV  in  which  the  stability 
characteristics  of  similar  aircraft  were  discussed.  The  spatial  error  assumption  of  plus  or 
minus  six  inches  (6")  in  x,  y  was  necessary  as  a  design  constraint  for  the  object  retrieval 
mechanism.  An  obvious  conclusion  of  this  assumption  was  that  construction  of  a  retriever 
capable  of  being  transported  by  the  aircraft  and  searching  the  entire  six  foot  (6’)  diameter 
'source'  bin  was  impractical.  Regardless,  these  parameters  were  assumed  until  flight 
testing  could  either  confirm  or  deny  their  validity.  The  assumption's  impact  on  subsystem 
design  was  that  a  retriever  must  be  capable  of  acquiring  disks  within  the  imaginary 
geometry  presented  by  the  aircraft's  spatial  and  stabilization  errors. 

(3)  The  vehicle  would  fly  forward,  backward,  and  sideward  during  the  flight.  As 
helicopters  fly  equally  well  in  any  direction  at  low  airspeeds,  additional  control  to 
accomplish  'hover  turns'  about  the  vehicle's  z-axis  seemed  unnecessary.  The  impact  was 
that  subsystems  must  be  designed  to  function  regardless  of  vehicle  orientation  within  the 
court. 

(4)  Separate  computers  would  be  required  for  the  guidance/flight  control  and 
control  of  the  mission  equipment  package.  Emphasis  was  made  that,  if  multiple  computers 
were  developed,  particular  attention  must  be  given  weight  and  volume  constraints. 
Additionally,  from  a  maintainability  viewpoint,  use  of  common  microprocessors  might 
reduce  spares,  necessary  expertise,  and  possibly  cost. 

(5)  At  least  one  team  would  be  capable  of  accomplishing  the  AUVS  task.  As  the 
team's  objective  was  to  win,  this  required  development  of  a  system  which  would 
accomplish  all  requirements  provided  by  the  competition  rules. 
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Miscellaneous  Taskers.  As  all  system  weights  to  this  point  were  extracted  from 
marketing  data,  and  the  aircraft  was  now  available,  the  aerial  vehicle  group  was  asked  to 
prepare  a  more  detailed  weight  statement. 

An  analysis  of  the  flight  path  which  would  result  in  as  few  control  inputs  as 
possible  resulting  in  the  shortest  flight  duration  was  requested. 

All  groups  were  asked  to  provide  test,  simulation,  and  evaluation  schedules  to  the 
system  engineer  for  the  Winter  and  Spring  quarters.  As  a  note,  this  was  not  possible,  due 
primarily  to  the  design's  infancy  and  team  inexperience. 

An  evaluation  of  how  strong  WREK  (Georgia  Tech  radio)  emissions  were  in  the 
competition  arena's  vicinity  was  requested  of  the  team's  electrical  engineering  contingent. 

Conclusion.  Apart  from  task-specific  meetings  with  the  various  equipment  lenders 
and  supporters,  this  EXCOM  was  one  of  the  more  historically  significant  meetings  from 
the  standpoint  of  influencing  the  ultimate  system's  design. 

Computer  Vision-System  Development- 

The  vision  working  group,  introduced  at  the  January  4th  EXCOM,  met  to  discuss 
requirements  and  establish  objectives  first  on  January  10th.  Goals  of  the  system  during 
this  initial  phase  included: 

(1)  to  locate  the  strobe  lights  inside  each  bin 

(2)  to  find  the  disks  in  the  'source'  bin 

(3)  to  provide  vehicle  position  feedback 

The  Dickerson  camera  with  pinhole  lens  provided  a  plus  or  minus  15°  field  of 
view.  It  was  hoped  that  a  combination  of  vehicle  position  and  appropriate  optics  would 
allow  the  system  a  complete  view  of  the  'source'  bin  without  having  to  move  the  aircraft  or 
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slew  the  camera  to  find  all  six  disks  arrayed  randomly  in  the  bin.  A  specific  goal  of  the 
group  was  to  recover  a  disk  position  to  within  .5  inches  when  the  target  was  located  less 
than  eighteen  inches  (18")  from  the  center  of  the  image  and  viewed  from  an  altitude  of  sixty 
inches  (60"). 

A  strobe  or  camera  flash,  mounted  on  the  aircraft,  was  shown  to  be  required,  based 
on  preliminary  camera  testing  of  similarly-colored  objects  in  the  laboratory  against  a  black 
backdrop. 

The  group  anticipated  using  a  single  processor  with  multiple  heads  to  perform  the 
dual  navigation/target  detection  functions. 

The  disks,  when  strobed,  would  be  recognized  as  'blobs’  by  the  Low  Level  Vision 
System  (LLVS)  onboard  the  aircraft.  A  High  Level  Vision  System  (HLVS),  located  at  the 
ground  station,  would  compare  the  blob  locations  to  current  world  knowledge  and  decide 
which  blob  was  the  target.  This  step  was  deemed  necessary  since  more  than  one  disk 
could  be  present  in  the  image  for  the  first  five  iterations  up  and  down  the  court.  The  HLVS 
would  then  output  a  vector  indicating  heading  and  distance  to  target,  relative  to  the  position 
of  the  vehicle  when  the  image  was  taken. 

Pacific  RPV  Visit- 

Mr.  John  Smith  arrived  at  Georgia  Tech  on  January  1 1th  specifically  to  answer 
team  questions  about  the  Bruiser  and  to  assist  the  aerial  vehicle  group  in  learning  required 
maintenance  actions. 

During  his  visit,  the  team  confirmed  stability  assumptions  made  about  the  airframe 
as  realistic,  particularly  so  if  the  SAS  employed  on  the  aircraft. 

The  Futaba  FP-9VHP  transmitter  used  to  command  the  Bruiser  possessed  nine 
channels  on  which  aircraft  and  aircraft  system  control  could  be  accomplished.  It  was 
anticipated  that  at  least  seven,  possibly  eight,  of  these  channels  would  eventually  be 
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required  by  the  airframe.  Therefore,  an  additional  radio  was  needed  to  ensure  adequate 
channels  were  available  to  control  onboard  payload.  As  Pacific  had  provided  the  team’s 
Competitor  without  radio,  purchase  of  additional  R/C  transmitter  was  directed.  Because 
simultaneous  use  of  both  radios  was  anticipated,  at  least  5  Mhz  spacing  between 
transmission  frequencies  would  be  required  in  order  to  eliminate  interference  problems. 

Additional  comments  made  during  Pacific's  visit  included: 

(1)  Payloads  of  from  five  to  six  pounds  in  the  forward  compartment  were 
necessary  on  previous  aircraft  to  obtain  adequate  balance. 

(2)  Electric  fish  reels  capable  of  winching  up  to  twenty  pounds  were 
recommended  for  use  to  the  object  retrieval  mechanism  designers. 

(3)  Transmitters  should  be  tested  adjacent  the  chain  link  fence  for  interference 
difficulties.  Additionally,  it  was  recommended  the  team  check  with  local  R/C  clubs  to 
determine  where  particular  frequency  problems  existed. 

(4)  Rights  should  be  accomplished  from  a  paved  surface.  Inexperience  with  the 
aircraft  necessitated  use  of  traditional  R/C  model  training  gear  [Figure  23].  This  gear, 
while  able  to  slide  easily  on  pavement,  preventing  roll-overs,  could  catch  on  grassy 
surfaces,  resulting  in  mishaps. 

(5)  A  ground  run  of  at  least  one  minute  was  directed  in  order  to  warm  up  the 
Bruiser's  engine. 

BmissrJEitsiEi&hi- 

After  failed  attempts  to  get  airborne  on  the  previous  day,  the  GT  Bruiser  flew  for 
the  first  time  on  January  23rd  [Figure  23].  This  flight,  ultimately  one  of  the  most 
successful,  demonstrated  the  aircraft’s  ability  to  hover  stably.  Assumptions  of  altitude  and 
attitude  variance  appeared  validated. 
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Figure  23  *  First  Flight  of  the  Georgia  Tech  Bruiser 


Executive  Committee  Meets  (January  25th). 

Comments  from  the  System  Engineer.  For  the  first  time  since  beginning  the 
project,  an  electrical  engineering  student  was  identified  to  lead  the  development  of  the 
system’s  object  retrieval  mechanism  and  to  oversee  vision  system  development. 

Groups  within  the  team  had  discussed  the  possibility  of  ’training'  the  system  to 
accomplish  several  of  the  more  basic  tasks  autonomously  and  then  using  these  as  ’building 
blocks'  toward  eventual  accomplishment  of  the  entire  mission.  With  significant 
development  of  the  flight  control  system  yet  to  be  accomplished,  however,  it  wras  felt  that 
integration  efforts,  not  originally  planned  until  the  Spring  quarter,  should  be  delayed. 

Competitors  Announced  bv  the  AUVS.  A  list  of  competitors  from  around  the 
United  States  and  a  team  from  Great  Britain  was  announced  bv  the  AUVS  on  January  23rd 


[Figure  24].  Various  universities  on  the  list  had  become  known  to  the  Tech  team  through 
personal  and  industrial  contacts.  From  this  original  announcement  through  the 
competition,  however,  little  knowledge  was  available  about  any  competing  design  scheme, 
hindering  any  type  of  traditional  'benchmark*  effort. 

Further  rules  clarifications  included  moving  the  vehicle  starting  area  from  one 
comer  of  the  volleyball  court  to  another  in  order  to  allow  teams  access  via  an  existing  door. 
Secondly,  teams  would  not  be  allowed  to  set  up  their  systems  prior  to  heats,  further 
restricting  any  procedures  developed  for  subsystem  and  component  initialization. 

No  part  of  the  system,  in  particular  antennas  and  cameras,  would  be  allowed  to 
extrude  through  the  chain  link  of  the  fence.  Existing  physical  barriers  around  the  arena 
were  to  be  considered  imaginary  planes  which  could  be  not  penetrated  physically  by  system 
hardware. 

Bins  would  probably  be  manufactured  of  some  opaque  plastic  material  and  disks 
would  be  tossed  into  the  'source'  bin  by  hand  [Figure  1].  Disks  landing  on  their  sides 
would  be  pushed  flat  and  no  disk  would  be  within  one  disk  diameter  of  the  bin  edge.  In 
regards  to  the  six  foot  bins,  the  Tech  team  eventually  requested  permission  from  the  AUVS 
to  construct  the  bins.  It  was  felt  that  access  to  as  much  competition  day  'hardware'  as 
possible  would  assist  the  testing  and  validation  effort.  Once  testing  was  completed,  the 
team  planned  to  sell  the  devices  to  the  AUVS  for  the  competition. 

Aerial  Vehicle  Engineer  Emphasis.  A  detailed  test  plan  was  developed  by  the  aerial 
vehicle  group.  Early  emphasis  was,  in  accordance  with  the  SEMP,  to  further  evaluate  the 
Bruiser’s  technical  characteristics.  In  particular,  analysis  of  available  thrust  would  further 
clarify  design  limits  to  be  imposed  on  payload. 
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List  of  Competitors  for  the 
First  International  Aerial  Robotics  Competition 
Cal  Poly  State  University,  San  Luis  Obispo,  California 
Teledyne  Ryan  Aeronautical,  San  Diego,  California 

California  Institute  of  Technology,  Pasadena,  California 
Hughes  Aircraft,  Malibu,  California 

Edinburgh  University,  Forrest  Hill,  Edinburgh,  United  Kingdom 

Georgia  Institute  of  Technology,  Atlanta,  Georgia 
Pacific  RPV,  Inc.,  Start-Up,  Washington 
Guided  Systems  Technologies,  Atlanta  Georgia 

Massachusetts  Institute  of  Technology,  Cambridge,  Massachusetts 
ISX  Corporation,  Thousand  Oaks,  California 

Mississippi  State  University,  Raspet  Flight  Lab,  MSU,  Mississippi 

University  of  Alabama,  Huntsville,  Alabama 
High  Density  Control  Company,  Huntsville,  Alabama 

University  of  Dayton,  Dayton,  Ohio 
Dayton  Chapters  of  AIAA,  ASME,  and  IEEE 

University  of  Texas  at  Arlington,  Arlington,  Texas 
UTA  Chapters  of  AIAA  and  IEEE 

Washington  State  University,  Pullman  Washington 
Hunt  Technologies,  Inc.,  Brainerd,  Minnesota 

Figure  24  -  Initial  List  of  Competitors 
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Early  steps  to  develop  the  flight  control  system  involved  establishing  a  database  of 
vehicle  geometric,  aerodynamic,  and  weight  characteristics  for  use  with  stability  and 
control  simulation  tools. 

Acoustic  and  vibration  level  tests  were  further  planned  to  identify  the  environment 
in  which  the  system's  sensors  and  payload  components  must  operate. 

Flight  Control  System  Development.  Pacific  RPV  proposed  developing  a  modified 
version  of  the  existing  SAS  for  use  with  the  autonomous  Bruiser.  Development  time  was 
to  be  donated  by  Pacific,  with  hardware  components  to  be  acquired  by  the  Georgia  Tech 
team.  A  site  visit  by  Mr.  John  Moore  of  Pacific  was  planned  in  early  February  to  further 
discuss  the  project. 

The  system  would  input  actual  vehicle  attitude,  altitude,  and  heading,  and  output 
desired  readings  through  an  RS-458  bus  to  all  five  control  actuators.  It  would  consist  of 
two  payload  'boxes':  the  sensors  and  signal  conditioners  in  one  box,  and  the  processor  in 
another.  Pacific  further  proposed  a  desired  sensor  suite.  An  altitude  sensor,  then  being 
developed  by  a  student  group,  was  to  be  interfaced  with  the  onboard  system. 

The  navigation  vision  system  would  provide  global  vehicle  position  to  an  outer 
control  ’oop,  which  would  then  generate  a  position  offset  vector  and  translate  the  command 
to  required  vehicle  attitudes.  An  initial  control  system  block  diag,  im  v  ~s  drafted  and  is 
depicted  in  Figure  25. 

The  control  system  engineer  further  recommended  that  vehicle  altitude  and  heading 
be  maintained  constant  in  order  to  simplify  control  loop  development.  In  response  to  this 
recommendation,  vehicle  orientation  was  chosen  to  be  maintained  constant  along  the 
longitudinal  axis  of  the  volleyball  court  with  aircraft  nose  (positive  vehicle  x-axis)  to  the 
target  bin.  A  constant  altitude,  to  be  determined  by  camera  field  of  view  primarily,  but 
secondarily  by  thrust  characteristics  obtained  in  flight  testing,  would  be  lown. 
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Figure  25  -  Preliminary  Flight  Control  System 
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GROUND  CONTROL 


In  addition  to  design  specifications  for  the  object  retrieval  mechanism  already 
outlined,  this  constant  altitude  decision  required  retraction  and  deployment  by  the  retriever 
from  hovering  flight. 

Market  Evaluation  of  Data  Link  Options  and  World  Model  Development. 

System  Communication.  Contact  with  a  several  communication  hardware  vendors 
was  initiated  in  order  to  find  between  the  aircraft  and  ground  station  (the  Futaba  radio 
transmitter  would  be  used  as  the  uplink).  Of  primary  importance,  however,  was 
identification  of  data  package  sizes  and  required  transmission  speeds.  Until  these  issues 
were  further  defined,  evaluation  of  competing  hardware  systems  was  essentially  a  'shot  in 
the  dark'. 

Likewise,  understanding  communication  required  between  the  system's  hardware 
components,  and  the  format  of  this  communication,  was  essential  to  developing  code  able 
to  receive,  store,  and  further  manipulate  system-developed  knowledge.  While  unknown  at 
this  point,  some  database  of  information  constituting  a  'world  model’  would  be  necessary 
in  providing  information  gathered  at  some  early  portion  of  the  flight  profile  for  use  later  in 
the  mission's  execution.  As  a  minimum,  it  was  envisioned  the  vision  system,  in  its  target 
detection  role,  would  'find'  all  six  target  disks  on  the  first  trip  to  the  'source'  bin  and 
remember  their  location  for  use  as  x  and  y  destinations  on  subsequent  shuttles  back  and 
forth. 

Team  Communication. 

In  addition  to  struggling  with  system  communication  requirements,  the  data  link 
group  attempted  to  establish  an  electronic  project  log  on  which  team  members  could 
provide  subsystem  updates  and  review  progress  by  other  groups.  Primarily  due  to  student 
unfamiliarity  with  electronic  mail  procedures,  this  log  was  seldom  used  and  eventually 
abandoned. 
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Block  2  Schedule  Objectives. 


An  updated  schedule  was  provided  to  the  team  on  February  8th.  The  broad  design 
goal  of  system  definition  through  product  engineering  resulting  in  a  preliminary  design 
benchmark,  as  outlined  in  the  SEMP,  was  still  on  schedule. 

Key  subsystem  objectives  were: 

(1)  Aerial  Vehicle  Group.  Complete  the  database  necessary  to  implement 
ARMCOP.  In  addition,  solid  modeling  using  I-DEAS  software  needed  to  commence  in 
order  to  address  unfolding  payload  weight  and  placement  issues. 

(2)  Mission  Equipment  Package  Group.  Preliminary  design  of  the  object  retrieval 
mechanism  was  to  be  completed  and  presented  to  the  team  for  comment  on  March  12th,  the 
final  Block  2  meeting. 

(3)  Data  Link  Group.  Wiring  diagrams  of  the  Futaba  transmitters  were  to  be 
obtained  in  order  to  design  digital  to  analog  boards  and  address  other  ground  station 
interface  issues.  In  addition,  results  of  the  ongoing  market  survey  of  feasible  downlink 
components  was  to  be  presented  for  discussion  at  the  February  22nd  EXCOM  meeting. 

(4)  Vision  Working  Group.  Evaluation  of  the  Dickerson  camera  in  order  to  select 
appropriate  external  navigation  cues  was  to  be  completed  by  February  22nd.  Additionally, 
a  second  camera  purchase  decision  was  to  be  made  after  risk  evaluation  by  students  in  the 
concurrent  engineering  course. 

Ultimately,  system  integration  was  planned  to  be  completed  by  June  4th,  with 
optimization  of  appropriate  hardware  and  algorithms  to  be  accomplished  during  the 
remaining  seven  weeks. 


53 


Right  Control  Development  Continues. 

U.S.  Army  Aerostructures  Group  Joins  the  Team.  On  February  1st,  formal 
approval  was  given  Captain  Greg  Walker  of  the  Aerostructures  Directorate  at  Langley, 
Virginia  to  participate  as  a  member  of  the  Georgia  Tech  team.  Captain  Walker's  primary 
objective  in  joining  the  group  was  to  use  lessons  learned  in  development  of  the  Georgia 
Tech  system  for  the  prototype  aircraft  being  developed  for  the  FFRRV  project  at  Langley. 
A  visit  was  planned  to  coincide  with  Mr.  John  Moore's  being  in  Atlanta  to  discuss  the 
aerial  robot's  flight  control  functions  the  weekend  of  February  8-10. 

SAS  Designer  Visit.  In  pre-visit  correspondence,  Mr.  Moore  expressed 
reservations  concerning  use  of  an  acoustic  system  to  sense  vehicle  altitude  citing  the 
Bruiser's  noise  environment.  Sound  pressure  levels  while  operating  over  a  grassy  surface 
had  been  measured  at  greater  than  75  dbA  at  three  meters.  Mr.  Moore's  experience  with 
marine  acoustic  positioning  systems  proved  high  noise  levels  difficult  to  correct  for.  In 
fact,  measurements  taken  during  early  flight  tests  over  a  concrete  surface  showed  vehicle 
noise  levels  of  98  dbA  at  between  five  and  ten  feet. 

During  Pacific's  February  8-10  visit  to  Georgia  Tech,  development  strategies  for 
the  outer  control  loop,  with  particular  emphasis  to  navigation  sensor  interface,  were 
debated.  An  alternative  to  the  proposed  onboard  vision  system  presented  by  both  Moore 
and  Captain  Walker  involved  positioning  at  least  three  cameras  on  the  ground  to  track  the 
vehicle's  position  vice  a  single  camera  on  the  aircraft  tracking  multiple  external  cues. 
Ultimately,  the  procurement  cost  of  a  third  camera  (two  were  already  being  discussed)  and 
calibration  times  necessary  to  implement  this  procedure  (only  three  set-up  minutes  were 
allowed)  resulted  in  abandonment  of  this  option. 

Additional  information  gained  during  Moore's  visit  included: 
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( 1 )  The  control  system  would  require  operational  frequencies  of  at  least  ten  cycles 
per  second  (Hz)  in  order  to  compensate  for  natural  frequencies  of  6  Hz  and  10  Hz  in 
vehicle  roll  and  pitch,  respectively. 

(2)  It  was  possible  to  take  advantage  of  the  vehicle's  ground  effect  limit  to  assist 
in  controlling  altitude. 

(3)  Selection  and  incorporation  of  Watson  sensors  in  the  system  made 
development  risks  extremely  low.  In  particular,  use  of  the  Watson  Attitude  Heading 
Reference  System  (AHRS-C300A)  [16]  would  allow  Mr.  Moore  the  ability  to  develop  any 
stability  augmentation  system  to  near  maturity  using  equivalent  hardware  available  to  him  in 
Washington- state. 

(4)  Batteries  necessary  to  operate  the  SAS  were  described  to  the  mission 
equipment  package  group  (responsible  for  power  generation).  It  was  recommended  that  a 
planning  capacity  of  twice  the  mission  duration  in  battery  power  be  designed  into  any  direct 
current  (DC)  supply. 

(5)  In  addition  to  the  one  minute  engine  warm  up,  sensors  would  require  at  least 
thirty  seconds  to  warm  up  and  an  additional  time  to  initialize  prior  to  flight. 

(6)  Development  of  the  SAS  required  Intel  development  tools.  It  was  expected 
that,  because  Georgia  Tech  was  an  educational  institution,  these  could  be  acquired  at  no 
cost  and  provided  through  the  team  to  Mr.  Moore. 

(7)  Mr.  Moore  would  be  out  of  the  country  in  early  June.  Therefore,  significant 
efforts  were  planned  in  order  to  progress  the  SAS,  if  not  fully  develop  it,  as  far  as  possible 
prior  to  his  departure. 

The  Ultrasonic  Altimeter.  Design  of  the  acoustic  altimeter  continued  during  project 
work  in  the  School  of  Electrical  Engineering  by  two  team  members.  The  strategy  was  to 
provide  a  0-5  volt  output  signal  proportional  to  the  Bruiser’s  altitude.  This  signal  would 
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constitute  the  altitude  error  signal  input  to  the  inner  loop  controller  and  operate  at  an  update 
rate  of  from  10  to  20  Hz. 

Helicopter  airframe  vibrations  and  noise  levels  were  measured  during  flight  testing. 
As  mentioned,  these  would  influence  function  of  the  altimeter. 

Polaroid  Environmental  Grade  Ultrasonic  Ranging  Units  and  a  6300  Ranging 
Board  were  selected  as  the  component  hardware.  Like  components  were  eventually  loaned 
to  the  team  by  GTRI. 

A  prototype  system  was  to  be  completed  by  the  end  of  Block  2  with  flight  testing 
scheduled  from  March  11-15. 

SAS  Follow-Up.  Correspondence  from  Mr.  Moore  on  February  28th  detailed  that 
hardware  development  for  the  augmentation  system  was  progressing.  Eighty-percent  of 
the  necessary  parts  were  already  on  hand,  and  code  would  soon  be  written.  It  seemed 
likely,  based  on  this  report,  that  a  SAS  might  be  deliverable  on,  or  about,  June  1st. 

Bruiser  Mishap- 

A  series  of  engine  tuning  problems  plagued  early  flight  test  efforts  throughout  the 
month  of  February.  On  February  26th,  the  Bruiser  suffered  its  first  mishap  when  strong 
winds  forced  a  hard  landing  [Figure  26].  As  only  the  landing  gear  suffered  any  real 
damage,  repair  was  accomplished  relatively  quickly.  This  type  of  work,  while  untimely, 
resulted  in  significant  gains  by  the  aerial  vehicle  group  in  maintenance  and  repair 
experience. 

Detailed  Functional  Analysis  Using  Quality  Engineering  Tools. 

Detailed  study  of  competition  requirements  using  quality  engineering  tools 
commenced  in  early  January  as  work  in  a  concurrent  engineering  course.  A  project  was 
assigned  to  develop  a  Quality  Function  Deployment  (QFD)  Planning  Matrix.  Customer 
requirements,  as  defined  in  the  AUVS  competition  rules,  were  deployed  against  an 
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Figure  26  -  Initial  Bruiser  Mishap 


essential  task  breakdown  (ETB).  Primary-level  tasks  w-ere  taken  from  top-down  evaluation 
of  likely  computer  code  requirements  developed  by  the  mission  planning  and  control  group 
in  mid-December  1990.  Target  values  for  each  essential  task,  using  execution  time  as  the 
objective  function,  were  established.  Finally,  tasks  determined  through  this  analysis  to  be 
the  most  critical,  would  be  further  deployed  against  the  work  breakdown  structure.  It  was 
anticipated  that  identification  of  hardware  components  associated  with  the  most  critical 
competition  tasks  would  provide  some  clue  as  to  how  best  to  apply  limited  resources  in 
further  system  development. 

Numerical  evaluation  of  the  relationship  between  primary-level  customer 
requirements  and  second-level  essential  tasks  using  a  software  package  called  'QFD 
Designer'  identified  the  five  most  critical  essential  tasks  [Figures  27  and  28 1.  Neglecting 
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Figure  27  -  Quality  Function  Deployment  (QFD)  Planning  Matrix 
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1  Top  Five  Essential  Tasks  | 

1 

Contingency  Operations 

2 

Retrieve  Disks 

3 

System  Maintenance 

Conduct  Readiness  Checks 

4 

Launch 

5 

Move  to  Source  Bin 

Figure  28  -  Top  Five  Second-Level  Essential  Tasks 


the  maintenance  tasks  and  contingency  operations  (not  to  be  considered  until  the  system 
worked  under  best  case  conditions  anyway),  disk  retrieval  and  system  launch  proved  the 
most  important  tasks  to  achieving  customer  satisfaction.  Rounding  out  the  top  five  is 
moving  to  the  source  bin.  It  should  be  noted  that  the  interaction  ratings  given  each 
relationship  between  customer  requirements  and  competition  task  were  subjective.  The 
ratings  presented  in  Figure  27  reflect  a  cumulative  assessment  of  five  teams  working  on 
these  QFD  tables  in  supporting  academic  work. 

It  was  possible  to  determine  which  hardware  components  were  most  applicable  to 
the  top  five  by  deploying  tasks  against  the  WBS  [Figure  29],  The  shaded  areas  of  this 
matrix  simply  show  where  system  maintenance  and  readiness  evaluations  must  be  applied. 
This  interaction  revealed  the  vision  system  to  have  greatest  responsibility  for  the  five  most 
important  tasks.  Of  secondary  importance  was  development  of  the  system  command 
software  which  would  provide  hierarchical  instructions  to  the  system's  various 
components.  Therefore,  emphasis  in  further  hardware  analysis  should  concentrate  on  the 
resources,  and  risk  involved,  to  develop  these  components  of  the  system. 
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Figure  29  -  Essential  Task  Deployment  against 
Level  3  Work  Breakdown  Structure  Components 
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Move  to  Source  Bin 


Although  the  Dickerson  vision  system  had  been  applied  in  landmark  tracking 
applications,  its  use  on  a  moving  platform  tracking  stationary  landmarks  was  new. 
Therefore,  the  decision  was  made  to  purchase  a  second  camera  and  double  development 
efforts  in  order  to  counteract  some  of  the  risk  involved  with  this  novel  application. 
Additionally,  as  it  comprised  one  of  the  more  important  sensors  within  the  system,  its  loss 
or  malfunction  would  be  a  serious  impact.  A  second  system  would  offset  these  effects. 

Second,  as  the  camera's  code  would  require  significant  development  effons,  and 
existing  code  would  only  function  on  certain  type  desktop  computer  systems,  the  team 
decided  to  purchase  a  386SX  computer  system.  It  was  further  assumed  that,  once  camera 
development  was  complete,  the  computer  could  be  used  to  supplement  the  Microvax  II  in 
the  mission  planning  and  control  station.  In  fact,  the  386SX  eventually  replaced  the 
Microvax  as  the  key  hardware  component  within  that  subsystem. 

Further  conclusions  from  the  QFD  evaluation  were  additional  design  constraints  on 
the  object  retrieval  mechanism.  Target  time  values  established  for  tasks  to  be  performed 
during  actual  execution  of  the  mission  showed  that  only  five  (5)  seconds  could  be  afforded 
the  retriever  to  pick  up  a  disk  once  located.  This  value  was  determined  after  an  analysis  of 
aircraft  velocity  necessary  to  translate  back  and  forth  between  the  bins  and  time  necessary 
to  acquire  and  deposit  the  target  disks.  Flight  velocities  from  three  (3)  to  six  (6)  knots  were 
assumed  with  deposit  of  the  sixth  disk  'scheduled'  at  the  180th  second  (the  three  minute 
limit).  Flight  tests  over  a  28'  distance  (bin  center  to  center)  using  the  smaller-scale  training 
aircraft,  revealed  that  airspeeds  of  greater  than  approximately  4.5  knots  resulted  in  the 
aircraft  attempting  to  accelerate  through  effective  translational  lift  (ETL).  Therefore,  slower 
velocities  in  transit  would  be  necessary,  further  restricting  retrieval  time. 
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Given  that  the  retriever  was  to  be  mounted  to  the  airframe  and  the  aircraft  was  to 
hover  at  a  constant  altitude  (approximately  sixty  (60)  inches),  this  meant  the  retriever  had  to 
drop,  acquire,  and  retract  within  the  5  second  time. 

Mitre  Corporation  Visit. 

On  February  21st,  Dr.  Marc  Slack  from  the  Mitre  Corporation  visited  Georgia  Tech 
to  be  briefed  on  the  project.  As  his  group  at  Mitre  was  primarily  interested  in  artificial 
intelligence  applications.  Phase  II  work  using  the  aircraft  as  a  technology  test  b  was 
determined  more  suitable  for  their  involvement.  However,  Dr.  Slack  agreed  to  review  the 
team's  efforts  periodically  as  another  objective  viewpoint 

His  comments  during  the  team's  briefing  highlighted  the  need  to  conduct  early 
testing  with  the  acoustic  altimeter.  Experience  at  Mitre  with  these  type  sensors  revealed 
different  sonar  characteristics  from  different  surface  materials.  Therefore,  evaluation  on  the 
competition's  black  plastic  surface  should  be  conducted  as  soon  as  practical. 

Additionally,  he  agreed  with  the  team's  early  January  assumption  that  at  least  one 
team  would  be  capable  of  performing  the  competition  mission.  In  fact.  Dr.  Slack 
characterized  Tech’s  proposed  flight  profile  as  the  most  likely  and  commented  that  any 
improvement  over  this  'baseline'  would  be  warranted  if  time  permitted. 

Concurrent  Engineering  Project  2. 

Continued  work  on  application  of  quality  engineering  tools  to  the  aerial  robot's 
development  required  identification  of  key  Technical  Performance  Measures  (TPM)  for  the 
hardware  and  software  components  highlighted  as  most  critical  to  customer  satisfaction 
[Figure  29].  These  measures  represent  the  characteristic  description,  in  performance 
specifications,  of  a  given  component.  Almost  as  a  byproduct  of  this  study,  and  for  the  first 
time,  a  relatively  clear  picture  of  the  entire  system  was  formed.  This  system  block  diagram 
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Figure  30  -  Preliminary  System  Block  Diagram 
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[Figure  30]  become  one  of  the  cornerstone  system  definition  tools  and,  with  minor 
changes,  resulted  in  near  complete  system  identification  by  the  end  of  Block  2. 

Block  2  Conclusions. 

A  final  Winter  quarter  meeting  was  conducted  on  March  15th.  Key  issues  to  be 
discussed  at  this  gathering  were  preliminary  design  of  the  object  retrieval  mechanism  and 
results  of  the  data  link  group's  downlink  market  evaluations. 

Object  Retrieval  Mechanism  CORM')  Design.  The  ORM  was  to  encompass 
development  of  a  retraction  system,  retriever,  and  associated  computer  codes  for  the 
function  of  each. 

A  GM8714  Pittman  gear  motor,  connected  to  a  load  shaft  contain  ng  an  aluminum 
spindle,  constituted  the  retraction  system's  hardware.  The  load  shaft  was  to  be  mounted 
underneath  the  aircraft  using  multiple  support  bearings.  The  retriever  was  held  in  its 
retracted  position  through  incorporation  of  an  electromechanical  brake.  An  optical  shaft 
encoder  was  used  to  let  the  retriever  know  its  altitude  about  the  ground.  A  Motorola 
MC68HCH  microcontroller  was  used  to  vary  input  voltage  controlling  motor  torque 
output,  process  data  collected  by  the  shaft  encoder,  energize/de-energize  the  motor  and 
brake,  and  to  time  components  thereby  assuring  smooth  operation. 

The  retriever  was  to  incorporate  nineteen  (19)  electromagnets  geometrically 
positioned  so  that  any  disk  present  underneath  the  one  foot  diameter  array  would  be 
touched  by  at  least  one  magnet.  Disks  were  to  be  detected  by  measuring  the  inductance  of 
the  magnetic  circuit,  which  is  affected  by  permeability  of  the  material  in  contact  with  the 
magnet.  Higher  voltage  readings  were  produced  whei:  magnets  touched  the  metallic  target 
disks.  Another  MC68HC1 1  housed  the  disk  location  algorithm  and  generated  a  100  Hz 
square  wave  in  order  to  perturb  the  detection  circuits  aiU  evaluate  the  inductance  readings. 
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Combining  retriever  and  detector  in  one  hardware  component  resulted  in  weight  and 
cost  savings.  Further  algorithm  and  layout  optimization  was  to  be  completed  concurrent 
with  system  manufacture. 

Data  Link  Market  Survey  Results.  With  intra- aircraft,  and  aircraft  to  ground, 
communications  becoming  clearer,  evaluation  of  feasible  hardware  components  for  use  as 
the  system's  downlink  was  simplified.  Further  identification  of  the  10  Hz  system 
operating  frequency  requirement  established  a  'bottom  line'  requirement  which,  when 
coupled  with  proposed  communications  packet  sizes,  dictated  subsystem  selection.  Unlike 
some  other  hardware  components,  which  were  selected  for  acquisition  cost  reasons,  packet 
size  and  operating  frequency  could  not  be  sacrificed  through  purchase  of  a  slower,  possibly 
less  expensive  system. 

Figure  31  presents  a  plot  of  required  baud  rate  versus  package  size  in  order  to 
achieve  the  10  Hz  cycle  time  specification.  Package  size  is  reflected  in  bytes  and  represents 
the  size  of  the  information  packet  being  transmitted  from  the  aircraft  to  the  ground.  The 
'effective'  line  of  the  chart  assumes  the  computer  uses  fifty  percent  of  its  available  time  for 
functions  other  than  communication.  Therefore,  in  order  to  achieve  appropriate  system 
frequencies,  an  effective  baud  rate  of  twice  the  original  must  be  obtained. 

As  information  package  sizes  to  be  downlinked  were  now  on  the  order  of  45  to  50 
bytes,  effective  rates  of  at  least  9600  baud  were  required.  Three  of  five  surveyed  systems 
met  this  requirement.  However,  only  testing  would  reveal  effective  rates.  Additionally, 
detailed  design  would  likely  result  in  an  increase  in  packet  size.  Therefore,  'overdesign'  of 
the  downlink  components  became  an  objective.  In  fact,  packet  sizes  approached  80  bytes 
near  competition  day. 
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Knowledge  About  the  Design- 


System  Definition.  A  list  of  technical  data,  hardware  nomenclature,  and  flight 
profile  scheme  was  developed  to  serve  as  the  system's  preliminary  design.  This  was 
ultimately  documented  in  the  previously-mentioned  Benchmark  1  report  and  represented  the 
team's  knowledge  about  the  design  to  this  stage. 


Figure  31  -  Information  Package  Comparison  with 
Required  Transmission  Speeds  (Baud  Rate) 
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Knowledge  About  the  Design  Curve.  Chapter  1  presented  discussion  of  the 
'Paradox  of  Sequential  Design'  and  qualitatively  highlighted  how  application  of  concurrent 
engineering  techniques  might  affect  this  situation. 

During  the  development  of  a  system,  it  would  be  impossible  to  assess  the 
knowledge  about  the  ultimate  design  which  is  known  at  any  point  in  the  development 
process.  For  example,  what  percentage  of  the  final  system  design  was  represented  by 
Benchmark  1?  However,  evaluation  of  the  design  process  in  retrospect,  a  unique 
opportunity  offered  by  this  competition,  allows  assessment  of  cumulative  knowledge  about 
the  design  at  any  point  in  the  design  cycle. 

The  definition  of  a  Work  Breakdown  Structure  (WBS)  was  presented  in  Block  l's 
discussion.  Recall  a  WBS  included  hardware  pieces,  computer  code,  services  and  other 
data  which  "completely  defines  the  problem".  Therefore,  it  could  be  assumed  that  complete 
knowledge  of  the  work  breakdown  structure's  components  would  constitute  complete 
knowledge  about  the  design. 

Level  4  of  the  system  ultimately  developed  is  presented  in  Figure  32  in 
chronological  order,  based  on  when  knowledge  of  that  WBS  piece  was  gained.  Each  level 
four  WBS  component  is  considered  an  equal  percentage  of  the  total  design’s  'knowledge'. 
For  purposes  of  this  paper,  the  team  was  considered  having  knowledge  about  a  component 
when  either  a  project  report  describing  some  subsystem  was  published,  an  algorithm 
describing  subsystem  computer  code  was  derived,  or  hardware  was  received.  Knowledge 
about  the  design,  in  this  context,  did  not  imply  resolution  of  integration  issues  or  changes 
made  from  an  original  version  in  component  or  hardware  optimization. 

At  the  conclusion  of  Block  2  (Winter  quarter),  approximately  32.7%  of  the 
ultimately-developed  system  was  known  [Figure  33].  A  more  detailed  discussion  of  this 
curve,  in  qualitative  terms,  is  deferred  to  the  discussion  of  results. 
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Figure  32  -  Chronological  Development  of  Level  4 
Work  Breakdown  Structure  Components 


68 


100.00% 
90.00% 
80.00% 
H  70.00% 

g  60.00% 

50.00% 

(D 

40.00% 

30.00% 

20.00% 

10.00% 


Freedom  of  Design 
o-  Knowledge  About  the  Design 


□ 

□ 


a 


0.00% 


4  0—4 - 1  I - 1 - 1 - 1 - 1 - 1 - 1 

Sep-  Sep-  Oct-  Nov-  Nov-  Dec-  Jan-  Jan-  Feb-  Mar- 

90  90  90  90  90  90  91  91  91  91 

DATE 


Figure  33  -  Freedom  of  Design  vs.  Knowledge  About  the 
Design  of  the  Georgia  Tech  Aerial  Robot 


Assumptions.  Assumptions  still  bearing  on  the  problem  are  outlined  below.  Many 
of  the  team's  original  'guesses'  had  become  knowledge  through  decision  or  validation 
through  testing. 

(1)  Insufficient  time  was  available  to  build  an  aerial  vehicle. 

(2)  The  aerial  vehicle  would  be  capable  of  holding  position  to  ±  3  inches  altitude, 
±  2°  heading,  and  maintaining  stable  hover  over  a  T  diameter  circle  on  a  calm  day. 

(3)  At  least  one  team  would  be  capable  of  accomplishing  the  AUVS  task. 

Design  Freedom. 

As  of  March  15th,  approximately  55.5%  of  the  available  design  freedom  remained 
to  determine  the  final  67.3%  of  knowledge  about  the  design  [Figure  33]. 
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Figure  34  -  Key  Block  1/BIock  2  Design/Organization  Events  (Cumulative) 
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Block  3  (April  to  June  1991) 

Refining  the  Design  Environment  and  System  Definition 


Design  Environment  Overview. 

Time.  As  classes  began  on  April  1st,  the  team  was  left  with  34.7%  of  the  system's 
available  development  time  (119  days). 

Student/Facultv  Involvement.  By  this  time,  the  team  had  begun  to  stabilize.  Many 
of  the  students  who  expressed  interest  with  arrival  of  the  aircraft  in  January  elected  not  to 
continue  efforts  with  the  team.  Design,  for  the  most  part,  was  complete,  and  difficult 
hardware  manufacture,  integration,  and  computer  code  development  remained.  A  key 
consideration  since  approximately  mid-February  was  students  who  were  to  be  graduated  at 
the  Block  3's  conclusion  (June  commencement).  This  was  to  have  a  tremendous  impact  on 
final  development  of  the  retrieval  mechanism,  'post  office',  and  other  peripheral  electronic 
interface  issues. 

Increased  Community  Involvement.  Near-continuous  difficulties  with  the  Bruiser, 
in  particular  the  drive  train  and  powerplant,  resulted  in  additional  R/C  modeler  participation 
with  the  team.  Two  individuals  from  a  second  radio-control  club,  the  Roswell  Air  Force 
(RAF),  began  work  with  the  now  experienced  aerial  vehicle  group  to  identify  and  solve  key 
vehicle  reliability  issues. 

Mitre  Corporation  Joins  the  Team.  Partially  in  response  to  the  information 
gathering  trip  by  Dr.  Slack,  and  in  pan  due  to  feedback  provided  through  electronic  mail 
concerning  mechanical  woes  of  the  aerial  vehicle.  Mitre  provided  the  team  a  $600  grant  to 
purchase  aircraft  spares  and  repair  parts.  In  return.  Mitre  was  officially  added  to  the  team's 
roster  on  March  27th.  This  represented  the  last  funding  received  by  the  project  during  this 
initial  phase. 
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Facilities.  Validation  of  the  navigation  camera  required  developing  a  scale  replica  of 
the  competition  arena  in  a  laboratory.  Necessary  space  was  finally  obtained  by  the  team  in 
mid-May. 

Competition  Update. 

A  third  competition  update  package  from  the  AUVS  revealed  that  two  of  the  original 
ten  competitors  had  dropped  out  [Figure  35]. 


Hardware  Components  On  Hand 

Aerial  Vehicle 

Bruiser  II 

Mission  Planning  &  Control  Station 

Microvax  II 

386SX 

Data  Link 

Futaba  9-Channel 

Futaba  7-Channel 

TRON-Tek  ATS  401 

Mission  Equipment  Package 

Stinger  70  Integrated  Vision  System 

Spring  Quarter  Reorganization  Meeting. 


The  design  team  met  on  April  1 1th  to  outline  accomplishments  to  date  and  strategize 
effort  for  the  upcoming  quarter. 

Team  Technical  Weaknesses.  While  generally  felt  the  team  had  grown  large 
enough  to  accomplish  most  design  objectives,  expertise  in  assembly  language 
programming  and  someone  familiar  with  digital/microcomputer  design  was  needed.  It  was 
agreed  specific  solicitation  would  be  made  using  the  bulletin  board  system  and  that  faculty 
advisors  would  seek  students  with  these  skills. 

As  previously  mentioned,  an  audio/video  transmitter/receiver  pair  had  been  received 
on  loan  for  evaluation  and  use  as  the  system's  data  downlink.  It  had  been  decided  that  only 
data  need  be  transmitted  by  the  vehicle  to  the  ground  station  and  that  any  necessary  visual 
package  would  be  developed  and  presented  using  the  downlinked  data  information. 

The  difficulty  in  realizing  a  combined  navigation/target  detection  camera,  and  risk  in 
combining  these  critical  functions  on  a  single  component,  resulted  in  the  decision  to  employ 
a  second  onboard  camera.  Optics  necessary  to  implement  this  decision  were  evaluated,  as 
well  as  further  analysis  of  necessary  external  vision  cues  for  use  with  the  navigation 
device.  This  decision  had  significant  impact  to  system  spares  in  that  purchase  of  a  second 
camera  had  been  accomplished  in  order  to  counteract  the  system's  risk  in  testing  and 
evaluation  with  the  device  onboard.  However,  implementation  of  this  design  choice, 
because  of  the  original  study,  was  quick  and  resulted  in  minimal  impact  to  system 
resources. 

With  most  major  subsystem  components  on  hand,  or  in  production,  purchase  of 
integration-enabling  hardware  and  software  was  required.  Battery  power,  cabling, 
commercially-applicable  software,  and  other  related  items  were  to  be  studied.  A  two-man 
team  was  established  to  further  evaluate  DC  power  requirements  and  sources  toward 
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reduction  of  an  anticipated  six  (6)  pounds  of  onboard  batteries.  This  six  pound  figure 
represented  approximately  33%  of  the  available  payload. 

Computer  Function  within  the  System.  With  anticipated  use  of  both  the  desktop 
386SX  and  Microvax  II  in  the  mission  planning  and  control  station  (MPCS),  and  multiple 
microprocessors  onboard  the  aircraft,  the  issue  of  which  computer  would  perform  which 
function  needed  to  be  addressed. 

While  microprocessors  were,  for  the  most  part,  subsystem  specific,  shared 
functionality,  such  as  analog  to  digital  conversion,  where  possible,  might  eliminate 
unnecessary  redundancy  onboard  the  aircraft.  Additionally,  this  would  not  require 
purchase  or  development  of  another  component,  resulting  in  both  financial  and  weight 
savings  to  the  system. 

On  a  much  larger  scale,  which  hierarchical  control  functions,  graphical  displays, 
and  databases  were  to  be  stored,  manipulated,  and  run  from  which  computer  within  the 
MPCS?  Pending  algorithm  development  necessitated  resolution  of  this  key  issue. 

System  Spares.  While  addressed  for  the  aerial  vehicle,  spares  and  repair  parts  for 
other  subsystems  had  not  been  considered.  Anticipated  test  flights  and  unanticipated 
failures  required  consideration  and  purchase  of  backup  components. 

Onboard  Post  Office.  Preliminary  discussion  of  an  onboard  post  office  was 
initiated  at  this  meeting.  Two  onboard  vision  systems,  the  stability  augmentation  system, 
and  object  retrieval  mechanism  were  all  designed  to  transmit  varying  byte  packages  to  the 
ground  control  station  for  either  storage  or  manipulation.  How  best  to  collect,  sequence, 
package,  and  transmit  this  data  needed  to  be  addressed  with  a  fifth  microprocessor,  or  at 
least  theorized  to  accomplish  this  function.  Additionally,  output  of  all  onboard  hardware 
components  was  in  RS-232  format,  while  the  TRON-Tek  downlink  transmitter/receiver 
pair  operated  in  TTL. 
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Integrated  Schedule.  Sequencing  components  into  some  organized  integration 
scheme  was  now  required.  Any  attempts  to  develop  schedules,  however,  had  proven 
difficult.  Continuing  mechanical  difficulties  with  the  Bruiser  made  integration  and  testing 
of  any  component  unpredictable.  Nevertheless,  an  integrated  schedule  was  overdue  and 
milestone  lists  and  test  schedules  were  requested  from  the  subsystem  engineers. 

Aerial  Vehicle  Status. 

On  April  14th,  one  of  the  volunteer  R JC  modelers  working  with  the  Bruiser  on  a 
test  stand  was  injured.  While  not  a  design  milestone  by  any  means,  the  event  amplified 
already  problem-plagued  product  testing  and  resulted  in  several  'down'  days  while 
necessary  safety  procedures  were  developed. 

The  following  update  was  extracted  from  an  April  18th  meeting  agenda  of  the  aerial 
vehicle  subsystem  group: 

Pavload  Placement.  Payload  layout,  to  include  detailed  weight  and  balance,  needed 
to  be  refined.  In  particular,  layout  decisions  resulting  in  modified  payload  shelf  and 
landing  gear  requirements  needed  to  be  made  so  that  details  could  be  forwarded  to  Pacific 
RPV  for  their  manufacture. 

Digital  SAS.  The  updated  delivery  date  was  now  June  15th  although,  at  one  point, 
March  15th  had  been  projected.  The  lack  of  access  to  Intel  development  tools,  thought  to 
be  available  to  Tech,  slowed  progress  significantly.  With  funds  available,  and  the 
continued  slip  of  the  digital  controller's  delivery  date,  a  decision  was  made  to  begin 
development  of  a  backup  analog  system. 

Altimeter.  The  acoustic  altimeter,  originally  projected  complete  by  March  10th,  was 
still  not  completely  assembled. 

ARMCQP  Modeling.  Stability  and  control  information  developed  in  project  work 
by  a  helicopter  stability  and  control  course,  made  continued  efforts  to  implement  ARMCOP 
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obsolete.  Additionally,  ARMCOP  was  found  too  conservative  for  this  scale  aircraft  and 
further  efforts  would  require  significant  flight  testing  which,  by  this  point  in  time,  was 
impractical. 

General  Comments.  After  repeated  attempts  to  obtain  necessary  product  data 
through  flight  testing  and  a  myriad  of  mechanical  failures,  the  aerial  vehicle  group  was  only 
able  to  react  to  malfunctions  as  quickly  as  possible  in  an  attempt  to  keep  the  Bruiser 
airborne.  Any  effort  to  forecast  requirements  was  viewed  with  a  great  deal  of  skepticism. 
Vision  System  Development, 

Concurrent  development  of  both  computer  vision  systems  was  initiated  on  April 
21st,  although  considerable  work  with  the  navigation  camera  had  already  been 
accomplished.  The  group  felt  that  similar  computer  codes  would  be  utilized  by  both 
cameras  and,  when  compared  to  the  navigation  task,  solving  the  target  detection  challenge 
was  trivial.  Therefore,  apart  from  an  analysis  of  optics  and  related  hardware  for  the  target 
detection  camera,  primary  focus  of  the  vision  working  group  was  to  maturation  of  the 
navigation  vision  system. 

Early  vibration  testing  with  the  Bruiser  mounted  on  a  test  stand  indicated  the  camera 
speed  was  faster  than  any  rotor  frequency.  Images  taken  over  time  with  the  camera 
attached  to  the  nose  fairing  revealed  no  shift  of  the  digital  data  from  'picture  to  picture’. 

Brainstorming  resulted  in  the  design  of  a  right  circular  conic  device  which  allowed 
the  navigation  camera  a  360°  field  of  view  [Figures  36  and  37].  This  prevented  unwanted 
camera  slewing  or  using  of  multiple  cameras  on  the  vehicle  to  view  all  five  external  vision 
cues.  The  sixth  cue,  originally  oriented  along  the  longitudinal  axis  of  the  volleyball  court 
[Figure  38],  was  deleted  due  to  its  obstruction  by  the  rotor  mast  assembly. 
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Cues  used  exclusively  for  Target  Bin  Area  Navigation. 
Cues  used  exclusively  for  Source  Bin  Area  Navigation. 
Cues  used  in  both  areas. 


Figure  38  -  External  Navigation  Cue  Layout 


Testing  with  the  TRON-Tek  equipment  began  immediately  upon  receipt.  Field  tests 
for  interference  revealed  significant  difficulties  in  image  transmission.  Various  antenna 
orientations  were  attempted  in  order  to  isolate  the  problem.  It  should  be  noted  the  TRON- 
Tek  was  not  designed  for  digital  data  transmission.  Therefore,  interference  in  image 
transmission  was  perceived  to  only  worsen  with  attempted  digital  communication. 


:t  Retrieval  Mechanism  Development. 


Emphasis  of  the  mission  equipment  group  at  this  time  was  primarily  retraction 
assembly  manufacture.  Coincidentally,  testing  with  the  smaller  training  aircraft  carrying  a 
representative  payload  extended  on  a  string  'tether'  revealed  significant  oscillations  of  the 
load  underneath  the  airframe,  eventually  resulting  in  loss  of  aircraft  control. 
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Therefore,  modified  supports  for  the  lines  attaching  the  array  to  the  retraction 
assembly  were  recommended  by  the  aerial  vehicle  group  to  the  MEP  team.  In  addition, 
decoupling  the  retriever  from  vehicle  dynamics  was  thought  feasible  through  design  of  an 
universal  joint  which  would  physically  mount  the  retriever  to  the  airframe.  Ultimately,  a 
wooden  mockup  was  produced  around  May  8th.  This  was  further  modified,  and 
eventually  refined,  using  computer-aided  solid  models. 

The  Onboard  'Post  Office'. 

A  student  meeting  was  conducted  on  April  23rd  in  order  to  resolve  functional 
requirements  of  the  onboard  post  office.  All  groups  with  a  component- specific 
microprocessor  were  represented  at  this  meeting. 

Four  microprocessors  onboard  the  aircraft  were  already  advanced  beyond 
preliminary  design.  Therefore,  rather  than  modify  the  existing  components  to  interface 
with  the  proposed-post  office,  the  post  office  board  was  to  accommodate  current  function 
of  the  various  microprocessors.  This  device  would  convert  the  data  from  RS-232  to  TTL 
format,  receive  input  at  a  variety  of  rates  and  buffer  the  speeds  to  an  appropriate  sequencing 
rate  between  data  transmissions,  sort  the  incoming  data  and  discard  undesired  information, 
and  package  and  sequence  downlinked  information  packages.  The  immediate  plan  was  to 
purchase  a  piece  of  hardware  which  could  handle  a  40  byte  information  package. 

Additional  decisions  from  this  meeting  included: 

(1)  The  386SX  would  handle  all  required  MPCS  functions,  less  an  agreed  upon 
graphics  display.  This  display  would  be  run  near  real-time  and  offline  from  primary 
MPCS  operations.  Information  to  drive  the  display  would  be  fed  through  a  serial  port  to 
the  Microvax  II  (the  assumed  graphics  driver). 

(2)  Only  seven  of  nine  available  uplink  channels  were  required  for  use  by  the 
aerial  vehicle,  even  after  including  SAS  and  kill  switch  functions.  Therefore,  only  one 
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uplink  Futaba  radio  would  be  used,  reducing  the  system's  requirements  for  a  second  D/A 
board,  although  the  second  would  continue  to  be  developed  as  a  component  spare. 

An  updated  system  block  diagram  reflecting  these  changes  is  shown  as  Figure  39. 
Interim  Schedule. 

Although  difficult,  further  efforts  to  develop  an  integrated  schedule  resulted  in  a 
weekly  task  list.  Key  dates  included: 

Week  of  13  May:  Install  and  test  Watson  sensor  suite  on  the  aircraft. 

Week  of  20  May:  Test  onboard  power  supply  and  TRON-Tek  components  in 

flight. 


Week  of  27  May:  Install/test  data  link  'post  office'  on  the  aircraft. 

Week  of  3  June:  Complete  development  of  the  outer  control  loop  in  anticipation 

of  Pacific  RPV's  visit  to  integrate  the  SAS. 

Week  of  10  June:  Accomplish  onboard  navigation  testing. 

Week  of  17  June:  Complete  onboard  navigation  testing. 

Week  of  8  July:  Conduct  an  autonomous  flight  demonstration. 

Week  of  15  July:  Begin  system  optimization  (note  this  was  originally  scheduled 
to  commence  the  first  week  in  June). 

Week  of  22  July:  Freeze  the  system. 


Competition  Update- 


The  AUVS  notified  participants  the  University  of  Edinburgh  had  left  the  event, 
leaving  only  seven  competitors. 
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Figure  39  -  Revised  System  Block  Diagram 
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Set  Backs. 


Bruiser  Crash.  On  May  7th,  while  conducting  test  flights,  the  pilot  lost  control  of 
the  Bruiser,  the  vehicle  caught  its  right  training  gear  skid  tube  on  the  turf,  rolled,  and 
crashed.  Damage  to  the  Kevlar  main  rotor  blades  (destroyed),  hub  (bent  spindle),  and 
servos  (gears  stripped)  was  substantial. 

Pavload  Evaluation.  Although  mentioned  as  early  as  mid-March,  no  significant 
layout  work  on  the  system's  payload  components  had  been  accomplished.  Weights,  in 
particular,  were  important  given  Pacific  RPV's  pending  visit  to  hand  off  the  SAS. 
Accurate  weight  estimates  would  allow  simulation  tools  to  calculate  loop  gains  necessary  to 
program  the  SAS.  Obviously,  the  more  exact  the  weight  estimation,  the  better  the  gain 
prediction.  Because  the  solutions  to  this  problem  were  scattered  about  the  system,  and 
because  attempts  by  the  aerial  vehicle  group  to  obtain  these  answers  had  failed,  the  system 
engineer  agreed  to  head  this  effort. 

Object  Retrieval  Mechanism  Components.  Many  of  the  parts  ordered  to 
manufacture  the  retraction  assembly  were  on  hand,  although  items  requested  to  be 
manufactured  by  the  Aerospace  Engineering  shop  were  not  yet  completed.  As  the  aerial 
robotics  effort  was  not  a  'funded'  research  project,  monies  to  ’buy'  shop  time  were  not 
allocated.  Therefore,  work  accomplished  for  the  team  was  on  a  'space  available'  basis. 

TRON-Tek  Interference.  Significant  interference  with  the  downlink 
receiver/transmitter  pair  forced  the  team  back  to  TRON-Tek  for  assistance.  Antenna 
matching,  power  sources,  and  hardware  component  failures  were  discussed  as  likely 
problem  sources. 

Student  Graduations.  Two  of  the  team’s  key  electrical  engineering  students  would 
be  graduated  at  the  end  of  Block  3.  One  engineer  was  responsible  for  developing  the  D/A 
card  used  to  interface  the  386SX  with  the  Futaba  transmitter,  while  the  other  had  done  all 
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preliminary  power  supply  and  post  office  work,  as  well  as  provided  contributions  to  the 
retriever's  development. 

Onboard  Power  Supply. 

During  Block  2,  some  preliminary  analysis  of  DC  power  was  accomplished  by  the 
MEP  group.  Nickel-Cadmium  (NiCd)  batteries  were  ultimately  selected  because  of  their 
high  current  capability.  EAC,  a  power  pack  manufacturing  company,  provided  quotes  on 
several  different  cell  packs  resulting  in  the  purchase  of  some  components  for  testing  on 
May  15th.  Other  pieces,  such  as  a  high  current  voltage  regulator  and  low  battery  detector, 
were  still  being  studied  for  application  to  the  system. 

Executive  Committee  Meeting  with  Mitre  Corporation  Partner. 

Dr.  Slack  of  Mitre  returned  to  Georgia  Tech  on  May  14th  to  receive  an  update  on 
the  project,  discuss  the  Benchmark  1  report,  and  to  overview  the  newly-distributed 
integrated  schedule. 

Among  the  issues  tabled  at  this  meeting  were: 

(1)  Make  or  Buv  Plan.  While  discussed  indirectly  at  earlier  meetings,  increasing 
testing  and  integration  requirements  would  likely  make  spares  and  repair  parts  a  significant 
issue  in  the  coming  weeks.  An  assessment  of  which  components,  if  failed,  could  be 
reproduced  within  a  time  which  did  not  result  in  schedule  delays  was  requested.  All 
hardware  exceeding  the  'no  schedule  days  lost'  guideline,  would  serve  as  a  preliminary 
'buy'  list  of  system  spares. 

(2)  Competition  Update.  Mr.  Michelson  of  the  AUVS  attended  this  update.  He 
informed  the  team  that  all  transmitters  would  be  confiscated  during  other  team  heats  in 
order  to  preclude  unintended  interference.  Therefore,  initialization  and  information 
download  procedures  were  to  be  again  be  reviewed  in  order  to  assess  the  impact  of  this 
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requirement.  Further,  Michelson  agreed  to  collect  information  necessary  to  establish  a  list 
of  team  operating  frequencies. 

Computer-Aided  Design  (CAD)  Assistance  in  Magnetic  Array  Layout 

On  May  14th,  the  MEP  subsystem  engineer  requested  assistance  in  developing  a 
manufacturing  template  for  the  magnetic  array.  CAD-based  tools  played  an  important  role 
in  the  development  of  this  system. 

Magnets  were  spaced  within  the  array  such  that  there  was  no  possibility  of 
'straddling'  a  disk.  Further,  any  disk  whose  center  of  gravity  was  within  the  +  6  inch 
spatial  error  must  be  touched  by  the  retriever.  Therefore,  some  optimal  geometry  of 
magnets  which  would  both  minimize  weight  and  maximize  the  probability  of  disk  retrieval 
needed  to  be  obtained.  Evaluation  using  CAD  tools  resulted  in  a  decrease  from  eighteen 
(18)  to  twelve  (12)  electromagnets,  thereby  decreasing  payload  weight  and  system  cost. 
Work  from  May  15th  through  June  14th- 

It  was  possible,  through  default  save  of  electronic  mail,  to  capture  some  of  the  more 
informal  correspondence  between  the  system  engineer  and  various  team  members.  This 
record  is  likely  the  most  detailed  account  of  team  activity  and  will  be  addressed  as  a 
candidate  historical  document  in  the  conclusions  to  this  paper. 

Spares  List.  As  emphasized  in  the  May  14th  Executive  Committee  Meeting,  a 
'make  or  buy  list'  was  needed.  Primary  attention  was  to  be  given  those  subsystem 
components  onboard  the  aircraft,  as  any  flight  mishap  could  result  in  significant  damage  to 
the  entire  system.  It  should  be  highlighted  here  that  the  integrated  schedule  took  this  into 
account  by  not  scheduling  flight  testing  of  all  key  components  simultaneously.  As  an 
example,  both  cameras  were  not  to  be  tested  on  the  aircraft  until  final  system  validation. 

Aerial  vehicle  spares  lists  were  heuristically  developed,  although  detailed  analysis 
of  model  helicopter  failures  may  have  made  this  evaluation  more  'proactive'.  A  second 
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engine  and  hub  assembly  were  purchased  from  Pacific,  as  well  as  spare  composite  and 
wooden  main  rotor  blades  and  a  variety  of  spare  parts. 

The  mission  planning  and  control  station  group  identified  workstations  which  could 
be  borrowed  at  the  'last  minute'  were  some  major  system  malfunction  to  occur. 

Given  that  the  vision  system  manufacturer  was  located  on  campus,  most 
components  deemed  appropriate  for  a  spares  list  could  be  replaced  within  one  day  at  no 
cost  premium. 

Within  the  data  link  subsystem,  conversations  with  TRON-Tek  revealed  their  ability 
to  replace  a  transmitter  within  two  to  three  days.  Two  complete  post  office  systems  were  to 
be  manufactured.  Beyond  this  second  component,  replacement,  as  was  the  case  for  any 
printed  circuit  board,  was  approximately  two  weeks  and  $250. 

The  only  spare  component  to  be  stocked  for  the  MEP  group  was  a  gear  motor  and 
electromagnets.  Further  testing  was  to  be  accomplished  in  order  to  evaluate  appropriate 
repair  parts  options. 

Pacific  RPV  Visit.  In  light  of  tremendous  reliability  and  maintainability  difficulties 
with  the  Bruiser,  Mr.  Smith  of  Pacific  RPV  agreed  to  an  unplanned  trip  to  Georgia  Tech  to 
assist  the  team  with  the  vehicle  over  the  weekend  from  May  30th  through  June  3rd. 
Feedback  from  this  trip  indicated  the  Bruiser  had  been  mechanically  optimized  for 
upcoming  receipt  of  the  stability  augmentation  system. 

Vision  System  Development  Update.  As  of  May  23rd,  the  vision  group  reported 
the  navigation  camera  still  on  schedule,  with  slight  delays  in  code  development  for  the 
target  detection  system. 

Code  manipulation  did  result  in  RS-232  camera  output  as  fast  as  32.25  Kbaud. 
Speed  increases  once  thought  to  require  component  replacement  at  a  cost  of  approximately 


86 


$100.  However,  this  1000%  speed  increase  was  accomplished  through  minor  software 
manipulation. 

Continued  testing  with  the  navigation  vision  system  revealed  it  to  be  oversensitive 
to  an  initial  guess  of  vehicle  position.  In  order  for  the  camera  to  function  correctly,  vehicle 
yaw  attitude  would  be  required  as  an  input  to  the  camera  microprocessor.  This  input 
requirement  resulted  in  modification  from  a  'one-'  to  'two-way'  communication  port 
between  the  post  office  and  the  navigation  camera. 

Outer  Control  Loop  Algorithm.  Estimates  on  May  23rd  put  coding  the  outer  loop 
control  algorithm  at  least  two  weeks  behind  schedule  due,  primarily,  to  coordination 
difficulties  between  the  code's  developer  and  programmer. 

Power  Supply.  As  of  May  25th,  no  battery  packs  had  arrived,  although  the  first 
order  had  been  placed  a  week  earlier.  In  addition,  further  delays  occurred  while  the  team 
searched  for  an  alternative  circuit  board  manufacturing  source.  This,  in  retrospect,  was 
unnecessary  in  light  of  the  system's  positive  budget  status. 

Object  Retrieval  Mechanism.  Printed  circuit  boards  (PCB)  for  the  retriever  arrived 
during  the  week  of  May  20th  and  were  being  loaded  with  components.  The  retriever  still 
required  additional  shop  work  and  these  hardware  delays  forced  a  postponement  in  lift 
evaluation  of  the  gear  motor  on  hand.  Shop  components  were  finally  received  and  handed 
off  to  the  MEP  group  on  May  28th.  Recall  that  analysis  of  mission  timelines  only  allowed 
5  seconds  for  disk  retrieval.  In  addition,  as  the  retriever  must  be  completely  up  prior  to 
aircraft  displacement,  retraction  as  quickly  as  possible  was  required.  Subsequent  testing 
was  expected  to  finalize  the  spindle  and  motor  arrangement  within  the  week. 

Post  Office.  Circuit  board  design  for  the  post  office  had  not  left  the  team  for  the 
manufacturer's  as  of  May  25th.  Final  transmission  speeds  of  the  four  microprocessors 
interfacing  with  the  post  office  were  required,  in  addition  to  finalized  byte  formats. 


87 


Acoustic  Altimeter.  The  altimeter  was  completed  on  May  27th,  roughly  two 


months  after  originally  projected. 

TRON-Tek  Interference  Difficulties.  Conversations  with  TRON-Tek  concerning 
the  team's  continuing  interference  difficulties  resulted  in  further  study  of  antenna  matching 
and  receiver/transmitter  orientation.  On  May  30th,  the  data  link  group  was  put  in  contact 
with  a  subcontractor  used  by  TRON-Tek  for  various  antenna  design  tasks.  Nose 
dimensions,  shelf  sizes,  component  layout,  and  receiver/transmitter  position  within  the 
system's  set  up  was  provided  this  organization  in  order  that  a  more  detailed  analysis  could 
be  completed. 

Spring  Quarter  Wrap  Up  Meeting. 

A  team  In  Progress  Review  (IPR)  was  conducted  on  June  7th.  Data  format  for 
transmission  to  the  onboard  post  office  was  reviewed.  Package  size  had  now  increased  to 
56  bytes,  primarily  due  to  the  camera's  inability  to  handle  the  more  cumbersome  position 
calculations.  This  validated  selection  of  the  TRON-Tek  hardware  over  a  marginally 
effective  9600  baud  modem.  A  review  of  subsystem  status'  showed  all  components  from 
one  (1)  to  three  (3)  weeks  behind  schedule. 

Use  of  the  Microvax  II  was  abandoned.  Maintenance  contracts,  valid  from  June  to 
June,  were  now  due  for  renewal  while  the  386SX  had  demonstrated  itself  capable  of 
handling  all  necessary  MPCS  functions.  Further  expenditure  of  monies  to  support  the 
Microvax  seemed  unwarranted.  It  was  still  anticipated  that  a  graphics  'driver'  would  be 
required. 

Updated  SAS  Delivery  Estimate.  June  9th  correspondence  from  Mr.  Moore  of 
Pacific  RPV  indicated  progress  on  the  SAS  had  slowed  considerably.  Although  he  offered 
an  older  SAS  to  the  team  until  delivery  of  the  new  component  could  be  accomplished,  the 
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team  felt  time  to  enable  this  new  SAS  would  detract  from  other  outstanding  issues. 
Delivery  was  now  anticipated  the  weekend  of  June  22-23. 

Only  when  the  Bruiser  was  shown  to  be  stable  and  reliable  in  hovering  flight  could 
subsystems  and  components  be  integrated  for  testing,  evaluation,  and,  hopefully, 
subsystem  validation.  The  team  was  directed  to  pursue  the  alternative  analog  controller  as 
quickly  as  possible. 

June  10  -  15;  A  Final  Spring  Push. 

Again,  excerpts  from  electronic  mail  logs  provided  an  overview  of  several  ongoing 
activities  before  the  quarter  break.  Team  activity  could  be  characterized  as  'non-stop'  from 
this  point  through  July  29th. 

Acoustic  Altimeter.  The  algorithm  used  to  determine  altitude  from  the  array  of  three 
acoustic  sensors  employed  an  averaging  scheme.  Were  a  sensor  to  fail,  this  scheme  was 
not  robust  enough  to  compensate.  However,  circuit  design  and  code  being  at  the  stage  they 
were  with  less  than  six  weeks  remaining,  a  decision  was  made  not  to  modify  the  altimeter. 

U-Joint  Manufacture  Supported  bv  Solid  Modeling  Tools.  With  preliminary  testing 
completed,  an  'airworthy'  design  of  the  universal  joint  was  required.  Several  two- 
dimensional  drawings  were  recreated  on  a  solid  model  already  in  use.  Although  many 
dimensions  were  missing  from  the  2-D  sketches,  clearances,  piece  dimensions,  and 
alignment  considerations  were  readily  obtained  through  manipulation  of  this  'soft 
prototype'  [Figure  401.  These  measurements,  extracted  from  a  combination  of  the  solid 
model  and  sketches,  were  eventually  used  in  the  shop  during  component  manufacture 
[Figure  41J. 
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Figure  40  -  I-DEAS  Solid  Model  of  Retraction  Assembly 


Figure  41  -  Completed  Retraction  Assembly 
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Knowledge  About  the  Design. 


Student  engineers  had  knowledge  of  slightly  greater  than  73%  of  the  ultimate 
design  at  the  conclusion  of  Block  3  [Figure  42]. 

Assumptions.  None  of  the  assumptions  outlined  at  the  conclusion  of  Block  2  had 
been  resolved:  that  there  existed  insufficient  time  to  build  an  aerial  vehicle;  that  the  vehicle 
would  be  capable  of  holding  position  to  ±  6  inches  in  x,  y  position,  +  3  inches  in  altitude, 
and  ±  2°  in  heading,  and  that  at  least  one  competitor  would  be  able  to  perform  the  specified 
mission. 

It  was  hoped  that  aggressive  flight  testing  would  establish  realistic  design 
parameters,  in  the  form  of  actual  vehicle  spatial  errors,  for  the  navigation  system. 
However,  reliability  and  maintainability  difficulties  precluded  any  significant  flight  activity. 
Tests  with  the  navigation  camera  on  a  tripod  in  a  gymnasium  with  lights  arrayed  at 
representative  distances  did  reveal  that  two-dimensional  spatial  accuracy  on  the  order  of 
inches  was  possible. 

Dgsign  Freedom. 

Roughly  15.3%  design  freedom  remained  to  accomplish  27%  of  the  design 
[Figure  42], 
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Figure  42  -  Updated  Freedom  of  Design  vs.  Knowledge  About 
the  Design  of  the  Georgia  Tech  Aerial  Robot 
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Figure  43  •  Cumulative  Design/Organization  Events  through  Block  3 
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Time.  9.9%  of  the  available  design  cycle  was  left  to  the  team  on  June  25th. 

Manpower.  Although  three  key  team  members  had  been  graduated,  the  team  had 
been  relatively  constant  since  the  end  of  Block  2.  Given  the  team's  roster,  however,  only 
eight  or  nine  of  seventeen  members  listed  were  involved  in  making  significant  effort  toward 
design  objectives. 

Budget.  While  it  became  necessary  to  oversee  spending  for  a  period  of  time  during 
conclusion  of  the  state's  fiscal  year,  the  team  enjoyed  sufficient  funds  to  complete  the 
effort. 

Competition  Update. 

As  teams  made  lodging  and  travel  arrangements  for  the  competition,  it  became 
apparent  that  only  five  of  the  remaining  seven  teams  would  actually  attempt  the  mission  on 
July  29th:  the  Massachusetts  Institute  of  Technology,  the  University  of  Dayton,  California 
Polytechnic  State  University,  the  University  of  Texas  at  Arlington,  and  Georgia  Tech 
[Figure  44]. 

Stability  Augmentation  System  Integration. 

A  final  trip  by  Mr.  John  Moore  of  Pacific  RPV  to  Atlanta  was  planned  over  the 
period  June  25th  through  July  1st  to  integrate  the  stability  augmentation  system.  It  was 
hoped  that  by  establishing  a  stable  vehicle  through  SAS  employment,  integrating  the 
onboard  power  supply,  and  mounting  the  forward  payload  shelf,  that  a  vehicle  ready  to 
accept  subsystems  as  rapidly  as  could  be  integrated  would  be  provided. 

Captain  Walker  would  also  arrive  at  Tech  to  observe  integration  issues  which  might 


be  applicable  to  his  FFRRV  project. 


As  a  minimum,  the  power  supply  was  necessary  to  fully  test  the  SAS  onboard  the 
aircraft.  A  temporary  payload  shelf  had  been  developed  to  'house'  the  Watson  AHRS. 
Once  adjusted  for  stable  flight,  the  retrieval  mechanism  was  planned  to  be  mounted  so  that 
control  loop  gains  might  be  adjusted  to  account  for  greater  mission  gross  weights  and 
different  centers  of  gravity,  as  well  as  to  compensate  for  the  changing  system  dynamics 
during  extension  and  retraction  of  the  magnet  array. 

After  arrival  on  June  25th,  Mr.  Moore  completed  some  final  coding  and  began 
bench  testing  the  SAS  on  Thursday,  June  27th.  Three  SAS  modes  were  to  be  coded:  (1) 
an  open  loop  (pilot-in-control),  (2)  closed  loop  (autonomous),  and  (3)  a  partially  open 
loop  (integrators  in  some  channels  open  and  others  closed).  This  latter  mode  facilitated 
autonomous  takeoff  when  the  system  was  artificially  constrained  by  the  ground. 

Development  of  components  all  over  campus  produced  a  variety  of  test  difficulties. 
First,  radios  being  used  to  finalize  design  of  the  D/A  boards  were  needed  concurrently  to 
test  the  SAS.  Typically,  these  radios  would  be  used  over  extended  periods  of  time  in  tests 
and  returned  to  the  aerial  vehicle  group  with  dead  power  supplies.  Second,  the  power 
supply  had  been  designed  and  built  to  provide  sufficient  DC  power  for  a  three  to  six  minute 
flight.  This  battery  life  was  obviously  insufficient  to  support  prolonged  flight  testing. 
Lastly,  the  batteries  used  required  twelve  hours  to  recharge. 

Ultimately,  alternative  power  supplies  were  'constructed'  from  D-cell  batteries. 
The  result  was  one  hour  of  transmitter  power  to  twenty  minutes  of  SAS  power  for  a 
required  three  hour  test  period. 

These  coordination  problems  resulted  in  a  poor  testing  effort  by  the  team  Mr. 
Moore’s  departure  on  July  1st  left  the  team  with  a  SAS  which  still  required  adjustment,  a 
sensor  suite  with  'dead'  roll  channel,  and  a  mechanically  marginal  vehicle. 
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itch  Development. 


Although  significant  work  was  already  accomplished,  by  the  time  the  student 
responsible  for  this  component  was  graduated,  little  technical  handoff  had  been  afforded 
the  team.  Therefore,  the  team  took  advantage  of  Captain  Walker’s  presence  in  Atlanta 
during  SAS  integration  and  tasked  him  with  completing  the  boards. 

The  D/A  card  was  finished  and  connections  from  computer-to-Futaba  transmitter 
were  manufactured.  A  'kill'  switch  was  wired  in  a  fail-safe  mode  to  the  safety  pilot 
holding  the  radio.  During  an  autonomous  flight  attempt  the  pilot  could  take  control  of  the 
aircraft  by  simply  releasing  the  switch.  Details  of  this  work  were  outlined  to  the  data  link 
group  prior  to  Captain  Walker's  departure. 

I-DEAS  Solid  Pavload  Model. 


As  already  mentioned,  packaging  was  recognized  as  a  crucial  issue  during  Block  2. 
Significant  attention  was  not,  however,  given  the  problem  until  mid-  to  late-June.  A  solid 
model  of  all  payload  components  to  be  mounted  on  the  aircraft  was  developed.  Through 
use  of  simple  geometric  shapes,  most  components  could  be  accurately  modeled. 

Each  component  was  detailed  and  weighed  before  attempting  the  model.  Once 
developed  as  a  solid,  physical  properties  could  be  calculated.  As  an  example,  given  the 
volume  of  a  camera  circuit  board  and  its  mass,  density  of  the  component  could  be 
numerically  obtained  and  entered  into  the  database  for  that  solid.  Recalculation  of  the 
solid's  physical  properties  could  then  yield  mass  and  moments  of  inertia  about  any  set  of 
axes.  Similarly,  grouping  components  into  subsystems  allowed  rapid  calculation  of  vehicle 
weights  and  moments. 

Spatial  relationships  were  determined  using  simple  point-to-point  options  available 
at  the  terminal.  The  data  obtained  was  then  entered  into  a  standard  spreadsheet  for 
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determination  of  the  vehicle's  center  of  gravity.  Ultimately,  complete  modeling  of  the 
aircraft  and  its  components  would  eliminate  the  spreadsheet’s  utility. 

The  forward  payload  area  is  shown  in  Figure  45.  Note  the  comparison  of  this  solid 
model  to  the  ultimate  vehicle  layout  forward  of  the  Firewall  in  Figure  46.  In  addition  to 
weight  and  balance  calculations,  lengths  determined  from  the  solid  model  were  translated  to 
cabling  and  other  physical  interface  problems. 

Antenna  Development. 

Antennas  specific  to  the  team's  proposed  flight  altitude  and  ground  station  location 
were  to  be  developed  and  delivered  the  week  of  July  1st  at  an  estimated  cost  of  less  than 
$500.  This  previously  unexpected  cost,  and  the  loss  of  two  electrical  engineers,  forced  the 
team  to  abandon  efforts  at  developing  the  backup  analog  controller. 

Shop  Work. 

Component  manufacture  and  access  to  a  shop  became  critical  issues  during  the  last 
four  weeks  of  preparation.  It  has  already  been  discussed  that  no  funding  was  available  to 
contract  out  shop  work.  Everything  requiring  shop  time  and  materials  was  being 
accomplished  on  an  'as  available'  basis.  The  Aerospace  Engineering  school,  however, 
agreed  to  allow  the  team  primary  access  to  the  AE  shop  over  a  period  of  three  days 
beginning  on  July  8th.  Efforts  were  taken  to  ensure  all  remaining  shop  work  was 
addressed  within  this  window.  Parts  to  be  manufactured  included  components  for  the 
object  retrieval  mechanism  and  aircraft  spares. 

Bruiser  Return  to  Washington  for  Repair. 

Continuing  difficulties  with  the  Bruiser  forced  the  team  to  send  a  member  with  the 
aircraft  back  to  Pacific  RPV  over  the  period  11-15  July.  Mechanical  problems,  as  well  as 
SAS  adjustments,  were  not  being  solved  adequately  at  Georgia  Tech. 
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Figure  45  -  I-DEAS  Solid  Model  of  Forward  Payload  Area 


Figure  46  -  The  Cieorgia  Tech  Aerial  Robot 
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Flight  testing,  while  at  Pacific,  was  characterized  as  successful.  On  one  flight, 
control  sticks  on  the  Futaba  transmitter  were  maintained  in  a  neutral  position  with  hand  off 
the  controls.  Altitude  variation  was  estimated  at  approximately  10  meters.  Even  with  this 
positive  progress,  a  tail-rotor  blade  separated  from  the  aircraft  in  flight,  continuing 
mechanical  troubles  for  the  aircraft. 

One  Week  to  Go. 

A  myriad  of  technical  details  preoccupied  the  team  from  early  July  on.  On  July 
22nd,  one  week  prior  to  the  competition,  the  systems  status  was  as  follows: 

Aerial  Vehicle.  The  vehicle  was  reassembled,  less  the  tail  rotor  assembly, 
following  its  return  from  Washington.  New  tail  rotor  blades  had  been  ordered,  but  were 
not  yet  available.  The  modified  payload  shelf  was  mounted  and  new  landing  gear  from 
Pacific  RPV,  large  enough  to  accommodate  the  object  retrieval  mechanism,  was  enroute. 
The  gear  was  designed  to  accommodate  lateral  and  longitudinal  rotation  of  the  retrieval 
mechanism  in  the  universal  joint  of  up  to  15°  in  both  axes.  Estimated  mission  gross  weight 
was  approximately  36  pounds.  Flight  testing  in  Washington  had  demonstrated  lift 
capabilities  slightly  over  40  pounds. 

Vision  Systems.  The  navigation  camera  was  mounted  to  the  aircraft.  Code 
optimization  continued,  with  particular  attention  devoted  to  the  navigation  camera's 
sensitivity  to  sunlight. 

Object  Retrieval  Mechanism.  Code  for  the  magnet  array  microprocessor  was  still 
incomplete.  Minor  mechanical  problems  still  existed  in  the  retractor's  ability  to  lift  the  array 
both  level  and  quick. 

Post  Office.  Debug  efforts  were  extremely  slow.  Minor  problems  had  occupied 
the  few  remaining  electrical  engineers  involved  with  the  project  for  nearly  four  weeks.  As 
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this  component  ultimately  determined  whether  or  not  the  system  could  communicate  with 
the  ground  station,  primary  attention  was  focused  to  finishing  the  post  office. 

D/A  Boards.  Hardware  was  near  completion.  Integration  to  the  386SX  was 
expected  to  be  rapid,  particularly  given  Captain  Walker’s  return  to  Atlanta  for  the 
competition.  On  July  23rd,  testing  verified  six  of  eight  D/A  channels  working  perfecdy. 

TRON-Tek  Downlink.  The  data  link  group  had  successfully  demonstrated  near 
90%  accuracy  with  available  antennas.  The  matched  antenna  set  discussed  previously  had 
still  not  been  received. 

Electronic  Mail  ’Blackout’. 

From  Friday  July  26th,  through  Monday  the  29th,  the  system  engineer  directed  all 
communication  between  team  members  be  conducted  face-to-face  or  by  telephone.  Time 
necessary  to  send  and  receive  electronic  correspondence  could  not  be  afforded. 

The  majority  of  the  team  worked  non-stop  from  Saturday  morning  until  the 
competition  commenced. 

Significant  attention  centered  around  completion  of  the  onboard  post  office  and 
vehicle  flight  testing.  It  was  not  until  early  Monday  morning,  however,  that  the  post  office 
was  finally  completed. 

Flight  testing  continued  to  be  plagued  by  reliability  problems.  On  Friday  evening, 
the  Bruiser  lost  a  tail-rotor  blade  for  the  second  time  [Figure  47]  resulting  in  damage  to  the 
tail-rotor  hub  and  'vertical  fin'  assemblies.  To  the  aerial  vehicle  group's  credit,  the  vehicle 
was  overhauled  and  ready  for  further  flight  testing  within  several  hours. 

Testing  with  the  SAS  on  Sunday  evening  showed  significant  improvement  in 
vehicle  stability  and  control.  Integration  of  the  acoustic  altimeter  with  the  SAS,  however, 
resulted  in  erratic  altitude  variation  leading  to  a  hard  landing  [Figure  48].  Finally,  at 
approximately  4:30  am  on  Monday,  July  29th,  an  engine  failure  grounded  the  system. 
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While  sufficient  time  was  available  to  repair  the  aircraft,  difficulties  with  the 
downlink,  a  nonfunctioning  retriever,  and  assorted  integration  issues  not  yet  addressed 
made  a  safe  and  successful  attempt  at  the  competition's  mission  profile  near  impossible. 
Given  the  time  available,  the  team  was  directed  to  attach  all  payload  components  to  the 
aircraft  and  prepare  a  static  display  of  other  subsystems. 


Aerial  Robot  Design  Cycle:  Block  4 
June 
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Figure  49  -  Significant  Block  4  Design/Organization  Milestones 
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CHAPTER  IV 


RESULTS 


The  First  International  Aerial  Robotics  Competition 


Nearly  60  students  from  five  universities  arrived  at  the  competition  arena  the 
morning  of  July  29th  for  the  First  International  Aerial  Robotics  Competition. 
Representatives  from  industry,  the  Department  of  Defense,  and  numerous  media 
organizations  supplemented  a  crowd  of  interested  spectators,  team  affiliates,  and  family 
members.  Throughout  the  weekend,  teams  had  been  afforded  the  opportunity  to  finally  see 
the  wide  variety  of  ’aerial  vehicles'  which  would  attempt  the  AUVS-sponsored 
competition. 

The  Massachusetts  Institute  of  Technology. 

As  expected,  the  MIT  team  intended  to  utilize  a  .60  series  R/C  helicopter.  In 
addition,  however,  the  team  began  construction  of  a  second  vehicle  after  arrival  in  Atlanta 
on  Friday  night.  This  system,  a  hovercraft,  utilized  a  garden  leaf  blower  and  small  'inner- 
tube'  arrangement.  Its  retrieval  system  consisted  of  a  small  'armlike'  device  which  would 
be  thrown  into  the  bin  and  sweep  the  area  for  disks.  The  MIT  helicopter  relied  heavily  on 
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vision  for  both  navigation  and  disk  retrieval,  much  like  the  Georgia  Tech  entry.  Rather 
than  use  an  onboard  vision  system  for  navigation,  however,  an  offboard  camera  tracked  the 
fluorescent-red-painted  forward  fairing  on  the  small  helicopter.  A  ground  station,  operated 
out  of  a  recreational  vehicle,  was  'connected'  to  the  vehicle  through  a  high-speed  modem. 

Ultimately,  MIT's  target  vision  system  failed,  forcing  their  withdrawal  from  the 
competition.  The  team  did  attempt  to  demonstrate  their  hovercraft  [Figure  501  and  retriever 
arm  under  remote-control  with  mediocre  results. 


Figure  50  -  Massachusetts  Institute  of  Technology’s  Hovercraft 


105 


The  University  of  Davton. 


Unlike  the  four  other  competitors,  Dayton's  team  spent  little  time  in  the  competition 
arena  over  the  last  few  days  leading  to  the  event.  A  series  of  laser  devices  were  mounted 
on  the  arena  fence  which  would  ultimately  create  a  set  of  ’laser  planes’.  It  was  interesting 
to  note  that  the  three  teams  intending  to  use  external  cues  all  placed  their  devices  at  virtually 
the  same  locations  about  the  fence.  Dayton's  aircraft,  another  .60  series  helicopter,  was 
mounted  on  tripod  landing  gear  which  suspended  the  aircraft  approximately  3  feet  off  the 
ground  [Figure  51].  A  retriever  arm  was  mounted  between  the  tricycle  landing  gear.  Once 
airborne,  the  vehicle  would  navigate  about  the  arena  by  ’riding’  on  the  laser  planes. 

The  vehicle  was  not  able  to  leave  the  starting  area.  Two  attempts  at  takeoff  resulted 
in  the  aircraft  tipping  back  on  its  landing  gear,  with  the  third  attempt  resulting  in  the  aircraft 
tipping  forward  and  right,  crashing  into  the  arena  floor  and  destroying  the  main  rotor 
blades. 

California  Polytechnic.. State  University- 

Cal  Poly  had  caused  considerable  concern  through  the  final  two  months  leading  to 
July  29th.  First,  their  system  had  been  described  as  being  'low  risk'  and  likely  to  achieve  a 
good  portion  of  the  mission  profile.  Second,  the  team  had  asked  permission  of  the 
competition  sponsor  to  ship  their  system  nearly  a  month  early,  something  that  never 
occurred.  It  had  been  revealed,  however,  that  the  team  was  composed  entirely  of 
undergraduate  engineering  students,  considered  by  many  a  liability  given  the  technical 
scope  of  the  problem. 

The  system  was  self-contained,  although  approximately  200  pounds  and  just  under 
the  6'  cube  size  restriction  imposed  by  the  AUVS.  This  hovercraft  [Figure  52]  employed  a 
superstructure  on  which  the  tactile  disk  retrieval  system  was  mounted.  As  the  system  was 
not  capable  of  flying  over  either  the  T  tall  ring  or  3'  tall  central  barrier,  the  arm  had 
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been  designed  to  reach  into  the  ring  and  sweep  the  entire  bin.  A  small  'gate'  would  close 
on  the  first  disk  sensed  resulting  in  all  but  that  disk  falling  off  the  retriever  when  the  arm 
was  retracted.  Once  at  the  central  barrier,  the  arm  would  drop  the  disk  into  a  chute  which 
projected  over  the  wall  and  aimed  at  the  target  bin.  Navigation  was  by  'dead  reckoning'. 
The  system  was  manipulated  by  hand  over  the  intended  'trajectory'.  Computers  would 
then  store  the  path  in  memory  and  duplicate  the  intended  route  while  autonomous. 

Although  the  team  eventually  put  their  system  in  the  arena,  the  vehicle  exhibited  no 
computer  control.  With  team  assistance,  the  retriever  was  demonstrated  to  work  as 
intended. 

The  University  of  Texas  at  Arlington. 

UT  Arlington  utilized  a  prop  tail  sitter  as  their  aerial  vehicle  [Figure  53]. 
Structurally  modified  from  another  aircraft  specifically  for  this  competition,  the  aircraft 
weighed  slightly  less  than  20  pounds.  Navigation  was  accomplished  by  means  of  a  Loran- 
type  system  comprised  of  acoustic  sensors  arrayed  around  the  competition  arena.  The 
onboard  computer  could  triangulate  position  from  the  various  distances  measured  by  the 
array  of  sensors.  Disk  retrieval  was  accomplished  by  means  of  a  target  detection  camera 
and  single  permanent  magnet.  All  necessary  computing  was  accomplished  onboard  the 
vehicle. 

In  its  only  heat,  the  vehicle  was  successfully  launched  and  found  the  source  bin. 
This  flight  had  been  intended  to  test  the  navigation  system  only,  thus  no  target  retrieval 
devices  were  attached  to  the  airframe.  As  the  vehicle  attempted  to  settle  into  a  hover,  the 
training  gear  impacted  the  side  of  the  source  bin  and  threw  the  vehicle  off  balance.  It 
impacted  the  arena  floor  resulting  in  damage  to  the  prop  and  at  least  one  control  surface. 
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Figure  53  -  UT  Arlington's  Aerial  Robotics  Team 
and  Prop  Tail  Sitter 


Competition  Results. 

The  AUVS  agreed  the  competition  had  failed  to  produce  a  clear  winner.  Therefore, 
the  $10,000  tuition  prize  was  divided  among  the  five  participants  commensurate  to  the  level 
of  success  achieved  in  the  competition  arena.  UT  Arlington  was  awarded  first  place  and 
$3,000,  the  University  of  Dayton  and  California  Polytechnic  State  University  each  received 
$2,000,  and  the  Massachusetts  Institute  of  Technology  and  Georgia  Tech  each  $1,500. 

Time  between  successive  aerial  robotics  competitions  had  originally  been 
envisioned  at  from  eighteen  months  to  two  years.  However,  as  the  competitors  had 
demonstrated  significant  progress  toward  the  competition's  requirements,  the  second  event 
was  decided  to  take  place  in  June  of  1992,  again  at  Georgia  Tech. 


Rules  modifications  were  discussed  at  a  post-competition  meeting.  Shorter  bins 
(less  than  1'),  modified  bin  placement  (central  to  each  half  of  the  volleyball  court),  different 
central  barriers  (paper  as  opposed  to  wood),  and  court  dimensions  were  addressed.  Many 
of  these  recommended  rules  changes  were  adopted  when  the  Second  International  Aerial 
Robotics  Competition  was  announced  in  early  October. 


Figure  54  -  Georgia  Tech's  Team  with  the  Bruiser  at  the 
First  International  Aerial  Robotics  Competition 
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CHAPTER  V 


ANALYSIS  OF  RESULTS 


Was  the  Customer  Satisfied  with  the  Result? 

The  success  or  failure  of  design  ultimately  rests  with  the  customer's  assessment  of 
the  product.  For  the  aerial  robotics  team  to  have  evaluated  its  success  would  have  been  to 
miss  the  point  of  concurrent  engineering  all  together.  Recall  Taguchi's  definition  of  quality 
relies  on  the  loss  a  product  causes  society.  Therefore,  the  Association  for  Unmanned 
Vehicle  Systems  was  asked  to  evaluate  the  five  competitors.  Using  customer  requirements 
developed  with  the  Quality  Function  Deployment  Planning  Matrix,  the  teams  were  rated  on 
how  well  their  entry  satisfied  the  competition's  objectives.  This  matrix  is  presented  in 
Figure  55.  Entries  were  graded  against  an  'ideal'  aerial  robot  system  as  perceived  by  the 
competition's  sponsor,  the  AUVS. 

Autonomous  Operation- 

Although  none  of  the  entries  exhibited  a  great  deal  of  autonomy  in  the  competition 
itself,  all  of  the  entered  systems  received  at  least  a  4  out  of  5.  Cal  Poly's  aerial  robotics 
system,  because  it  required  no  ground  station  or  external  navigation  cues,  received  the 
highest  score.  Georgia  Tech  and  MIT  both  received  the  '4'  scores  because  they  required 
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both  offboard  computing  and  external  navigation  cues.  This  indicated  a  philosophy  of 
autonomous  systems  on  the  part  of  the  AUVS  which  may  have  been  learned  through 
stronger  customer  interface  during  the  conceptual  design  phase. 

Vehicle  Requirements. 

Specifically,  aerial  vehicles  were  perceived  to  require  some  type  of  VTOL 
capability,  at  least  six  minutes  of  flight  endurance,  and  capable  of  controlled  flight  within 
the  geometry  of  the  competition  arena. 

All  of  the  vehicles  except  Cal  Poly’s  received  a  maximum  score  of  5.  This  was 
attributed  to  technology  spin-off  potential,  while  the  Cal  Poly  hovercraft  was  competition- 
specific. 

Contest  Time  Constraints. 

These  constraints  were  the  three  minute  system  set-up  time,  vehicle  start  period, 
and  three  minute  mission  performance  time. 

Note  that  only  those  teams  who  actually  attempted  the  competition  received  a  score. 
UT  Arlington's  acoustic  cues  were  perceived  to  be  the  quickest  to  install  and  their  vehicle 
was  reasonably  reliable  in  the  start  area.  Both  the  University  of  Dayton  and  Cal  Poly  were 
rated  better  than  MIT  and  Georgia  Tech,  although  their  set  up  and  vehicle  preparation  times 
were  rated  less  than  desirable  by  the  customer. 

The  customer  allowed  considerable  deviation  in  interpretation  of  the  set-up  rule,  as 
evidenced  by  Dayton's  positioning  of  their  laser  devices  more  than  24  hours  before  the 
competition  and  MITs  emplacement  of  a  data  link  component  the  night  before.  Feedback 
from  the  AUVS  highlighted  mission  execution  time  limit  as  the  most  critical.  The  lesson 
learned  was  that  the  team's  interpretation  of  the  important  requirements  was  incorrect.  On 
this  point,  the  'Strong  Interface  with  the  Customer'  tenet  of  successful  concurrent 
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engineering  was  certainly  violated.  In  fact,  consideration  of  set  up  time  restrictions  ruled 
out  other,  possibly  more  optimal,  navigation  and  communication  methods. 

Contest  Restrictions. 

These  restrictions  included  limiting  the  number  of  team  members  inside  the  court  to 
start  the  aerial  vehicle  to  two,  landing  inside  the  bins  only,  and  picking  up  disks  singly. 

Georgia  Tech  and  MIT,  again,  received  a  'O’  score.  However,  the  customer 
perceived  the  system,  if  demonstrated,  would  have  performed  to  a  '5'  score.  Cal  Poly  was 
penalized  for  the  number  of  people  necessary  to  operate  their  system.  Both  Dayton  and  UT 
Arlington  scored  relatively  well,  and  were  perceived  capable  of  a  maximum  score  given 
their  systems  had  actually  flown. 

Course  Specifications. 

These  customer  requirements  dealt  with  the  course  dimensions  and  composition,  to 
include  bin  placement  and  the  designated  start  area. 

Only  those  systems  which  actually  left  the  start  area  received  a  score.  Cal  Poly, 
although  given  a  '4'  score,  was  not  perceived  to  be  capable  of  remaining  within  the  arena 
boundaries  under  autonomous  control.  Texas  again  received  the  highest  score,  although  all 
of  the  remaining  teams,  including  Texas,  were  viewed  capable  of  remaining  within  the 
course’s  dimensions  in  flight. 

Environmental  Considerations. 

Systems  were  required  to  be  robust  to  the  environment  presented  in  a  competition 
environment  (ie.  photo  flashes,  noise,  etc.)  and  capable  of  operating  in  July-type  weather 
for  Atlanta. 

While  only  California  Polytechnic  State  University  and  the  University  of  Texas  at 
Arlington  received  scores,  all  systems  entered  were  perceived  capable  of  satisfactory 
performance  in  this  setting. 
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Disk  Specifications. 


All  systems  entered  were  judged  to  have  theoretically  sound  retrieval  subsystems. 
Cal  Poly's  mechanical  arm  was  determined  to  possess  the  greatest  probability  of  successful 
disk  retrieval.  The  Texas  retriever  was  ranked  the  worst  design  due  to  its  vision-assisted 
disk  acquisition  and  single  permanent  magnet 

In  general,  although  the  designed  systems  fell  short  in  many  categories  of  satisfying 
the  AUVS  mission  requirements,  the  event  was  judged  a  success.  The  "look  at  reality  in 
the  engineering  world"26,  was  highlighted  at  having  made  all  the  competition's  participants 
winners. 


What  Went  Wrong  with  the  Hardware? 

The  'Bruiser'  Aerial  Vehicle- 

The  underlying  assumption  throughout  design  of  this  robotics  system  was  that 
development  of  an  aerial  vehicle  at  Georgia  Tech  was  impractical  given  the  competition's 
date  and  short  design  cycle.  Therefore,  selection  of  an  'off-the-shelf  aircraft  would  allow 
the  team's  design  resources  to  be  aimed  at  development  of  the  more  critical  payload 
components. 

While  selection  and  receipt  of  the  Bruiser  represented  the  first  increment  of 
knowledge  about  the  design  gained  by  the  team,  development  of  a  stable  system  capable  of 


26.  "1991  Aerial  Robotics  Competition  -  Lessons  Learned  and  Ingenuity", 
Unmanned  Systems.  Vol.  9,  No.  4,  Fall  1991,  p.  45. 
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accepting  hardware  for  test  and  validation  was  never  obtained.  As  of  the  competition  date, 
the  aerial  vehicle  was  more  than  six  weeks  behind  schedule.  Mechanical  malfunctions 
plagued  the  aircraft  during  the  entire  system  development  cycle.  Specific  reasons  for  the 
Bruiser's  poor  performance  are  to  be  addressed  in  other  studies,  however,  drive  train 
component  reliability  was  at  the  forefront. 

The  team's  supposition  that  subsystem  validation  and  testing  could  be  accomplished 
on  the  Bruiser  resulted  in  no  alternative  airframe  being  developed  as  either  a  competition 
backup  or  test  aircraft.  In  addition,  the  team  considered  assessment  of  the  aircraft's 
vibratory  and  acoustic  environment  and  its  impact  on  payload  components  critical.  No 
simulation  packages  could  adequately  duplicate  this  regime,  and  without  this  analysis, 
integration  would  surely  prove  less  than  successful. 

Evaluation  of  the  aircraft's  dynamics  could  not  be  accomplished  through  available 
simulation  tools,  due  primarily  to  scaling  problems  at  this  small  size.  Extensive  calibration 
efforts  were  not  possible  owing  to  the  short  development  time  available.  Even  with  these 
tools,  significant  flight  testing  was  likely  required  in  order  to  validate  their  solutions.  This 
type  testing,  given  the  high  failure  rate,  was  not  possible. 

In  sum,  mechanical  failure  of  the  airframe  ultimately  resulted  in  the  team's  inability 
to  exhibit  anything  in  the  arena  on  July  29th.  Because  the  system  could  not  be 
demonstrated  to  the  customer,  'O'  ratings  were  given  in  four  of  seven  customer  requirement 
categories. 

The  Home  Court  Advantage’. 

The  team  was  perceived  to  have  a  significant  advantage,  situated  virtually  adjacent 
the  competition  arena.  Ambient  conditions  in  the  court,  electromagnetic  spectrum,  and 
other  key  issues  could  easily  be  evaluated.  However,  none  of  these  studies  were 
accomplished,  although  discussed  at  more  than  one  team  gathering.  Power  was  not 
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available  in  the  arena  until  one  week  prior  to  the  competition,  severely  hampering  vision 
system  development.  Efforts  to  solve  this  problem  went  unrewarded. 

Finally,  the  team  spent  considerable  time  discussing  the  impact  of  WREK  radio 
tower’s  location  adjacent  the  court,  commenting  on  the  contribution  of  the  chain-link  fence 
to  communication  difficulties,  and  highlighting  the  unusual  spectrum  created  by  a  national 
HAM  radio  convention.  Even  with  this,  no  interference  testing  with  the  TRON-Tek 
hardware  was  conducted  in  the  arena  until  July  28th. 

Integration  Issues. 

While  many  of  the  system's  components  did  not  reach  maturity  by  the  competition 
date,  those  that  did  suffered  from  an  incomplete  consideration  of  key  hardware  integration 
issues.  Electromagnetic  interference  among  payload  components,  proper  grounding, 
cabling,  and  a  variety  of  other  interface  issues  continued  to  surface  as  late  as  the  morning  of 
July  29th. 

What  was  flawed  was  the  team's  perception  of  integration.  As  outlined  in  the 
design  team's  SEMP,  integration  was  to  be  accomplished  during  the  Spring  quarter  (Block 
3).  The  system  engineer  failed  to  realize,  however,  that  integration  is  to  be  designed  into 
the  product,  and  not  a  consideration  at  some  specific  point  in  the  design  cycle.  Design  For 
Manufacturability  (DFM)  and  Design  For  Assembly  (DFA)  are  important  considerations  at 
the  conceptual  design  phase.  These  tools,  as  highlighted  in  Chapter  2,  are  not  yet  available 
on  a  wide  scale  to  the  Georgia  Tech  team. 

While  the  Joint  Project  Office's  documents  on  UAV  development  were  used  as 
guidelines  for  this  system,  insufficient  attention  was  paid  the  DoD’s  emphasis  on  Joint 
Integration  Interfaces  (JII),  or  interface  specifications.  Establishing  criteria  for  the 
mechanical  and  electrical  interface  of  one  component  to  another  is  as  key  to  establishing 
performance  specifications  for  that  single  hardware  piece. 
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Finally,  in  addition  to  DFM  and  DFA,  the  system  must  exhibit  appropriate  Design 
For  Test  (DFT)  attributes.  Particularly  given  that  all  components  were  to  be  tested  and 
validated  on  the  competition  aircraft,  sufficient  power  supply,  as  an  example,  must  be 
available.  Regardless,  a  system-level  test  scheme  must  be  established  to  ensure  key 
component  development  and  subsystem  integration  milestones  are  met. 


What  Went  Right  with  the  Hardware? 

Vision  System  Development. 

While  some  problems  still  remain,  the  navigation  vision  system,  originally 
perceived  a  system  weakness,  was  successful  in  demonstrating  the  order  accuracy 
necessary  for  implementation  in  this  mode.  The  use  of  this  component  on  a  moving  system 
tracking  stationary  landmarks  was  a  first.  Modifications  to  camera  output  speed,  among 
other  functions,  were  successfully  implemented. 

TRQN-Tek  Application  IQ  Digital.  Data  Transfer- 

Although  designed  to  transmit  audio  and  video  information  over  short  distances,  the 
team  was  able  to  provide  new  application  for  the  TRON-Tek  hardware.  Successful  digital 
data  transfer  between  two  terminals,  operating  at  19,200  baud,  was  achieved  for  over 
fifteen  minutes  with  100%  accuracy. 

Sophistication  of  Design- 

While  viewed  by  some  as  a  team  downfall,  the  system's  sophistication  resulted  in 
positive  evaluations  from  a  variety  of  sources.  Application  of  the  system  to  other  tasks, 
originally  intended  in  Phase  II,  has  already  been  initiated  in  discussions  with  the 
Environmental  Protection  Agency  (EPA).  As  an  indicator  of  the  design's  versatility,  none 
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of  the  competition's  major  rules  changes  necessitated  significant  deviation  from  the  team's 
current  design  strategy.  Clever  engineering  of  the  conic  device  and  inductance  scheme  in 
disk  retrieval,  were  likely  candidates  for  duplication  on  other  school  systems. 


What  Was  Wrong  with  the  Design  Environment? 


Time- 

Establishing  the  Design  Environment.  In  academia,  establishing  the  design 
environment  is  a  key  time  segment  of  the  system's  overall  development  cycle. 

Industry  involved  in  system  or  product  design  are  typically  organized,  financed, 
equipped,  and  managed  to  accomplish  that  task.  Departments  with  engineers  trained  in  the 
design  process  are  located  in  facilities  which  provide  access  to  design-oriented  software 
packages,  computer-aided  engineering  workstations,  and  other  relevant  design  tools. 
Finances  adequate  to,  as  a  minimum,  develop  a  successful  design  proposal,  are  provided 
each  design  task.  Lead  design  engineers  exist  to  supervise  the  process,  assisted  by 
company  policy  and  established  methodologies  which  have  been  proven  successful  in 
previous  design  endeavors. 

In  contrast,  Georgia  Tech's  Aerial  Robotics  Design  Team  did  not  begin  to  form 
until  after  receipt  of  the  AUVS  competition  announcement.  Facilities,  budget,  and 
experience  were  extremely  limited  during  earlier  phases  of  the  design  cycle.  Less  than  43 
weeks  were  available  to  develop  the  system,  while  prototype  development  in  industry 
usually  takes  place  over  a  period  of  years. 

Student  Engineers.  Given  other  academic  requirements,  it  is  nearly  impossible  to 
adequately  compensate  students  involved  in  a  design  project  of  this  magnitude. 


119 


To  compound  difficulties  presented  by  a  shortened  design  cycle,  student  engineers 
were  required  by  contest  rules  to  make  the  "significant  contribution  to  their  entry"27.  In 
addition,  student  team  members  were  required  to  be  enrolled  "full-time"  and  scheduled  for 
at  least  twelve  hours  per  quarter/semester. 

A  review  of  student  involvement  revealed  that  less  than  1.6  hours  of  the  required 
twelve  per  school  period  were  awarded  as  credit  toward  work  on  the  aerial  robotics  project. 
Again,  considering  the  academic  engineer's  industrial  counteipart,  approximately  13.3%  of 
a  student's  work  week  was  'funded'  by  the  aerial  robotics  project,  while  nearly  100%  of 
the  design  engineer's  time  is  compensated  for  work  on  design-related  efforts. 

Participating  in  a  primarily  volunteer  role,  classroom  requirements  must  take 
precedence.  Project  schedules  which  conflict  with  courses  or  other  research  become 
meaningless.  Unfortunately,  the  system  engineer  must  acknowledge  the  conflict  at  the 
expense  of  the  system. 

Manpower- 

The  primary  manpower  deficiency  of  the  Georgia  Tech  team  was  late  involvement 
of  key  student  electrical  engineering  expertise.  23.1%  of  knowledge  about  the  design, 
represented  by  Level  4  Work  Breakdown  Structure  components,  was  assigned  the  Mission 
Equipment  Package  group.  Because  they  were  not  involved  until  early  in  Block  2,  over 
41%  of  the  design  cycle  was  lost. 

Likewise,  the  inability  in  academia  to  provide  team  continuity  resulted  in  loss  of 
three  critical  team  members  to  graduation  at  a  crucial  stage  in  the  system's  design. 


27.  Association  for  Unmanned  Vehicle  Systems,  "Official  Rules",  p.  2. 
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Facilities. 

Integration  efforts  were  not  well  served  by  the  'patchwork'  nature  of  facilities 
available  to  the  design  team  [Figure  13].  While  the  team  attempted  to  implement  electronic 
communications  tools  to  assist  in  subsystem  'cross-talk',  hardware  lacked  the 
multidisciplinary  'flavor'  which  likely  would  have  eased  integration  efforts.  Working 
primarily  in  discipline-specific  facilities,  time  constraints  periodically  allowed  the  team  to 
wander  from  multidisciplinary  interaction  to  technical  specialization.  Team  interaction  was 
limited,  for  the  most  part,  to  group  meetings  and  electronic  mail. 

Establishing  some  type  of  communications  network  would  have  reduced  the  impact 
of  scattered  lab  space.  However,  a  wide  variance  in  knowledge  of  e-mail  procedures 
resulted  in  abandonment  of  these  initiatives.  No  common  capability,  as  described  in  the 
successful  tenets  for  implementation  of  concurrent  engineering,  was  available. 


What  Was. Right  with  the  Pgsign  Environment? 


Budget. 

The  team  was  successful,  through  innovative  cost  sharing  methods,  to  finance  the 
aerial  robot's  design  within  budget.  Aggressive  industry  solicitation,  advantageous 
partnerships,  and  industrial  charity,  when  combined  with  generous  university  funding, 
allowed  development  of  an  advanced  system  for  less  than  $20,000. 

Experience  Gained. 

It  was  generally  recognized  that  the  ability  to  work  on  a  hardware-oriented  project 
while  still  in  an  academic  environment  provided  a  unique  opportunity  to  most  graduate  and 
undergraduate  engineers.  A  multitude  of  practical  lessons  learned,  both  from  engineering 
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and  team  interaction  standpoints,  allowed  unique  understanding  of  the  variety  of  technical 
specialties  involved  with  the  robot’s  design. 


Was  Application  of  Concurrent  Engineering  Techniques  Effective? 

Chapter  2  presented  the  reasons  for  applying  concurrent  engineering  techniques  to 
any  project  were  to  achieve  higher  quality  at  lower  cost  in  shorter  time.  Having  already 
addressed  the  quality  issue  through  an  evaluation  of  the  AUVS  assessments  of  system 
performance  and  just  oudined  the  success  enjoyed  in  building  the  system  under  budget,  an 
evaluation  of  development  time  will  be  presented. 

The  complete  Freedom  of  Design  vs.  Knowledge  About  the  Design  plot  for  the 
aerial  robotics  effort  is  shown  in  Figure  56.  Figure  16  presented  Schrage  and  Rogan's 
analysis  of  the  qualitative  effects  on  these  curves  through  application  of  concurrent 
engineering  methods.  If  the  baseline  curve  represented  the  typical  sequential  design 
process,  application  of  CE  techniques  should  move  the  curve  to  right,  increasing  its  slope 
in  comparison  to  the  baseline  [Figure  16].  Conversations  with  Sobieski  revealed, 
unfortunately,  that  these  curves  are  strictly  qualitative  plots  and  that  no  formulae  exist 
describing  the  'typical  sequential  design  process'.  Therefore,  unless  a  project  is 
accomplished  using  both  traditional  sequential  methods  and  concurrent  engineering, 
comparison  strictly  on  the  basis  of  these  curves  is  not  possible.  As  direct  comparison 
between  the  two  design  methodologies  is  not  normally  possible,  what  is  accomplished, 
qualitatively,  by  the  curve  shift  achieved  through  CE  application? 

Intersection  of  the  Two  Curves.  The  point  where  these  curves  cross  corresponds  to 
a  time  in  the  design  process  when  knowledge  of  the  design  equals  the  remaining  design 
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Figure  56  -  Freedom  of  Design  vs.  Knowledge  About  the  Design 
Plot  for  the  Complete  Development  Cycle 
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I  1  Positive  Intersection  Region 

Figure  57  -  Design  Curve  Intersection  Relationship 


freedom.  This  is  a  positive  relationship  when  the  intersection  occurs  above  the  50%  line, 
meaning  that  more  than  50%  of  the  design  freedom  remains  to  accomplish  less  than  50%  of 
the  design  [Figure  57].  This  figure  shows  how  the  shift  described  by  Schrage  and  Rogan 
results  in  movement  of  the  intersection  point  above  the  50%  mark.  When  this  intersection 
occurs  below  the  50th  percentile  line,  the  project  suffers  a  'design  deficit'  where  the  team 
must  engineer  a  larger  percentile  of  the  product  than  resources  remain  to  accomplish  that 
design.  Such  was  the  case  with  Georgia  Tech's  design  effort  on  the  aerial  robot.  This 
relationship  is  easier  to  understand  if  the  T -knowledge  about  the  design  curve',  termed 
here  the  'knowledge  left  to  design',  is  plotted  [Figure  58].  The  'knowledge  left  to  design' 
plot  can  be  considered  analogous  to  a  stack  of  bills  which  must  be  paid  and  the  'freedom  of 
design'  to  a  checkbook  ledger.  Figure  58's  intersection  occurs  on  July  15th,  meaning  the 
Tech  team  worked  in  a  'design  deficit’  for  nearly  96%  of  the  design  cycle.  Better 
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Figure  58  -  The  Georgia  Tech  Aerial  Robotics  Team's  Design  Deficit 


125 


DATE 


application  of  concurrent  engineering  techniques,  to  future  projects  should  shift  the 
knowledge  about  the  design  curve  up,  and  the  knowledge  left  to  design  relationship  down, 
producing  a  surplus  design  environment  earlier  in  the  design  cycle. 

It  is  likely  impossible  to  attain  a  complete  design  cycle  in  a  surplus  of  knowledge  to 
freedom.  Almost  intuitively,  at  some  point  in  the  conceptual  design,  an  investment  of 
freedom  of  design  must  be  made  in  order  to  initiate  the  process.  In  this  case,  selection  of 
the  Bruiser  could  be  likened  to  that  investment  while,  more  typically,  identification  of  a 
powerplant  on  other  aircraft  systems  normally  becomes  the  first  significant  step  toward 
refining  a  design  during  the  preliminary  stages. 
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CHAPTER  VI 


CONCLUSIONS 


Whv  Did  Quality  and  Development  Time  Suffer?: 


Underlying  the  ten  characteristics  for  successful  implementation  of  concurrent 
engineering  should  be  "a  computing  environment  which  allows  a  shared  information 
database  with  open  access  to  all  participants  in  the  CD  process  [which]  can  be  used  for 
automated  configuration  management  and  control"28.  While  recognized  early  by  the  team, 
this  important  requirement  was  never  implemented. 

In  order  for  the  team  to  succeed,  some  type  of  computer  bulletin  board,  either 
created  to  specifically  support  the  aerial  robotics  design  effort,  or  utilizing  existing 
electronic  mail  capabilities,  must  be  adopted.  Pugh  [14]  highlights  electronic  white  boards, 
for  example,  as  means  to  visualize  large  quantities  of  data  which  can  be  easily  manipulated. 


28.  Daniel  P.  Schrage,  Concurrent  Design;  A  Case  Study,  p.  1 1. 
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The  team  was  relatively  successful  in  establishing  responsibility  for  subsystem 
development  using  a  Work  Breakdown  Structure.  Alignment  of  the  team  on  specific 
hardware  components,  rather  than  on  interfaces,  created  integration  difficulties  later  in  the 
design  cycle.  Although  a  Systems  Engineering  Management  Plan  (SEMP)  was  drafted,  it 
lacked  the  depth  necessary  to  truly  be  the  'cornerstone'  management  document  it  was 
intended  to  be. 

Some  time  must  be  devoted  to  understanding  system  responsibilities.  Better 
attention  to  interface  of  subsystems,  and  components  within  subsystems,  must  be 
accomplished.  Team  realignment  away  from  hierarchical  system  decomposition  and 
oriented  to  system  function,  clear  integration  responsibilities,  and  mutually  agreed  upon 
system  milestones  must  be  incorporated  into  the  team's  SEMP. 

Strong  Interface  with  the  Customer. 

While  the  Georgia  Tech  team  enjoyed  a  geographical  advantage  in  being  located 
close  to  the  competition's  sponsor,  quality  assessments  by  the  customer  of  fielded  systems 
indicate  this  advantage  was  not  adequately  exercised.  Inappropriate  levels  of  importance 
applied  to  various  customer  requirements  likely  resulted  in  bypassing  feasible  design 
alternatives. 

Wherever  the  customer  is  concerned,  the  competition  sponsor  must  be  consulted. 
If  design  choices  are  made  based  on  customer  requirements,  the  AUVS  should  have  been 
given  the  opportunity  to  assist  in  developing  and  ranking  key  requirements. 

QFD  matrices  should  be  completed  as  early  in  the  design  process  as  feasible.  Much 
of  the  system  block  diagram  obtained  through  detailed  analysis  of  the  quality  function 
deployment  tables  and  technical  performance  parameters  could  have  been  realized  earlier. 
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Multifunctional  and  Multidisciplinary  Teams. 


The  team  was  successful  in  obtaining  key  technical  expertise  in  all  critical 
specialties.  In  some  cases,  however,  critical  disciplines,  like  electrical  engineering,  were 
missing  from  the  team  for  a  significant  period  of  time. 

The  new  team  should  be  realigned  to  function,  rather  than  hardware  component. 
Where  possible,  multidisciplinary  groups,  as  subsets  to  the  team,  should  be  formed.  A 
central  facility  must  be  established  in  order  to  ensure  the  team's  multidisciplinary  nature  is 
optimized  through  interaction. 

Design  Benchmarking  and  Soft  Prototyping. 

As  with  the  first  competition,  efforts  at  competitive  benchmarking  will  likely  be 
difficult.  However,  further  work  in  soft  prototyping  should  be  initiated  as  early  as  is 
feasible.  Use  of  computer  solid  models  was  shown  effective  in  solving  a  variety  of  system 
geometric  issues.  Further  work  would  likely  compliment  the  recommended  electron] 
database. 

Simulation  of  Product  Performance  and  Manufacturing  and  Support  Processes. 

Lack  of  available  or  applicable  tools  indicated  much  work  is  needed  in  this  area, 
particularly  so  for  unmanned  aerial  vehicles.  Simulation  facilities  should  be  utilized,  where 
possible,  existing  automated  design  tools  must  be  calibrated  for  this  scale  system,  and 
manufacturing  and  support  tools  must  be  obtained  and  employed. 

Early  Involvement  of  Subcontractors  and  Vendors. 

Clearly  defined  responsibilities  between  the  team  and  its  affiliates  must  replace 
unwritten  agreement.  Undue  reliance  on  perceived  development  responsibilities  threatens 
the  entire  system. 

Continuity  of  the  Teams. 
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Care  must  be  given  to  assignment  of  critical  component  development 
responsibilities  to  likely  degree  candidates.  Further,  a  balance  of  undergraduate  and 
graduate  participation  should  continue  in  order  to  assure  long-term  interest  in  the  project. 
New  system  engineers  should  be  identified  during  the  preceding  cycle  for  the  upcoming 
design  period. 

Practical  Engineering  Optimization  of  Product  and  Process  Characteristics. 

Where  appropriate,  component  optimization  candidates  should  continue  to  be 
identified.  While  unlikely,  particularly  in  the  academic  environment,  that  significant 
optimization  time  will  be  available,  an  optimization  plan  must  be  in  place. 

Experiments  to  Confirm/Change  High  Risk  Predictions  Found  Through  Simulation. 

Eventual  application  of  Taguchi  methods  and  other  statistics-based  quality 
techniques  will  require  significant  record-keeping  efforts.  Detailed  procedures  to  establish 
lessons  learned  logs,  record  reliability  and  maintainability  data,  and  document  the  ongoing 
design  cycle  across  all  subsystems  must  formally  be  established  in  the  SEMP.  Where 
applicable,  availability  of  'like'  data  should  be  pursued  in  order  to  more  quickly  establish 
significant  information  records  on  which  quality  tools  may  be  applied.  For  example,  use  of 
aircraft  maintenance  data  obtained  from  local  R/C  clubs  may  allow  more  statistically- 
significant  analysis  of  helicopter  maintenance  and  reliability  trends. 

Corporate  Focus  on  Continuous  Improvement  and  Lessons  Learned. 

The  team  should  assign  one  or  more  engineers  the  responsibility  of  documenting 
ongoing  design  efforts.  Again,  formal  procedures  should  be  established  in  the  SEMP. 
Both  written  and  pictorial  records  should  be  kept.  Where  possible,  use  of  'default'  record 
keeping  systems,  like  electronic  mail,  should  be  used. 

General. 
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Failure  to  understand  the  quality  engineering  tools  and  their  application  resulted  in 
'random'  use  during  this  initial  phase.  Winner  [1]  presents  a  table  of  nearly  25  quality 
engineering  tools.  An  understanding  of  each  of  these  tools,  their  application,  and  typical 
results  would  significantly  aid  the  system  engineer. 

Lastly,  Georgia  Tech  should  seek  every  means  to  ensure  students  are  able  to 
continue  participation  in  this  event.  Valuable  hardware-oriented  design  experience  and 
multidisciplinary  exposure  through  the  team  enhance  learning  far  beyond  academic 
exercises  driven  by  textbook  problems. 
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APPENDIX  1 

SELECTED  SYSTEM  EQUIPMENT  DESCRIPTION 
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Nomenclature 


Manufacturer 
Max  Gross  Weight 
Empty  Weight 
Power  Plant 

Rotor  Diameter 
Height 
L  ngth 
Width 


Bruiser  II  Remotely-Piloted  Vehicle 

Pacific  RPV,  Start-Up,  Washington 

(Takeoff)  40  pounds  (estimated) 

23  pounds  (estimated  in  AUVS  configuration) 

Serie  ST  77i  Super  Tartan 

3.95  Brake  Horsepower  (w/o  tuned  exhaust) 

4.50  Brake  Horsepower  (estimated  w/  tuned 

exhaust) 

60  inches 

19  inches  (keel  plate  to  top  of  main  rotor  hub) 
75  inches  (original  forward  fairing) 

28  inches  (landing  gear) 
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Nomenclature 


Modified  S ASS YS-1  AutoLeveler 


Pitch  Position 
Pitch  Rate 
Roll  Position 
Roll  Rate 
Position  Accuracy 
Yaw  Rate 
Velocity  Range 
Power  Supply 
Weight 

Spare  Analog  Inputs 
Options 


+  45  degrees 
To  100°  per  second 
+  45  degrees 
To  100°  per  second 
.1  degree 

To  100°  per  second 

0  to  100  kilometers/hour  for  corrected  position 
12-16  volts  DC  at  450  mA 
18  ounces 

3  at  +  10  volts  range,  12  bit  resolution 
RS-232  serial  operation  data  output 


Nomenclature 
Manufacturer 
Physical  Dimension 
Weight 

Full  Frame  Rate 
Partial  Frame  Rate 
Accuracy  (small  fiduciary) 
Resolution  (small  fiduciary) 
RAM  Memory 
ROM  Memory 
Processor 
Frame  Size 


Stinger  70  Integrated  Vision  System 
Dickerson  Vision  Technologies,  Atlanta,  GA 
10  inches  x  5  inches  x  1  inch 
6.9  ounces  (estimated) 

100/second  (maximum) 

1000/second  (maximum) 

1/20  pixel  (RMS) 

1/200  pixel  (RMS) 

96K  bytes 
64K  bytes 
8  MHz  68000 
165  x  192  pixels 
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Nomenclature 

Airborne 

Ground-Based 

Manufacturer 

Physical  Dimension 

ATS-410A  Transmitter 
ATS -400  Receiver 

Weight 

ATS-410A  Transmitter 
ATS -400  Receiver 

Frequency 

Power  Output 

RF  Impedance 


ATS-410A  Transmitter 
ATS-400  Receiver 

TRON-Tek,  Inc.,  Tulsa,  Oklahoma 

5  inches  x  5  inches  x  1.25  inches 
5  inches  x  5  inches  x  2  inches 

1.5  pounds  (estimated) 

1.6  pounds 

460  MHz 

1  Watt  (30  dBm)  ±  1  dBm 
50  Ohms 


APPENDIX  2 
GLOSSARY 
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AE  - 

Aerospace  Engineering 

AHRS  - 

Attitude  Heading  Reference  System.  The  nomenclature  for  an  attitude  and 
rate  sensor  package  manufactured  by  Watson  Industries. 

ARMCOP  - 

A  simulation  package  used  to  model  vehicle  stability  and  control 
characteristics  developed  by  NASA. 

ATDC  - 

Advanced  Technology  Development  Center 

ATF  - 

Advanced  Tactical  Fighter 

AUVS  - 

The  Association  for  Unmanned  Vehicle  Systems.  Sponsor  of  the  First 
International  Aerial  Robotics  Competition. 

AV  - 

Aerial  Vehicle 

baud  - 

Computer  transmittal  rate  in  bits  of  information  per  second. 

CAD  - 

Computer-Aided  Design 

CALS  - 

Computer-Aided  Acquisition  and  Logistics  Support 

CAM  - 

Computer-Aided  Manufacture 

CCRC  - 

Cobb  County  Radio  Control  Club 

CD  - 

Concurrent  Design 

CE  - 

Concurrent  Engineering.  May  also  be  used  as  an  acronym  for  Civil 
Engineering. 

CoC  - 

College  of  Computing 

COMOK - 

Computerized  Mock-up 

D/A  - 

Digital-to- Analog 

DC  - 

Direct-Current 

DFA  - 

Design  for  Assembly 

DFM  - 

Design  for  Manufacturability 

DFT  - 

Design  for  Test 

DL  - 

Data  Link 

DoD  - 

Department  of  Defense 

EE  - 

Electrical  Engineering 
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EPA  - 
ETB  - 
ETL  - 
EQFD  - 

EXCOM  - 

FFRRV  - 

GST  - 
GT  - 
GTRI  - 
HLVS  - 
Hz  - 
IDA  - 

I-DEAS  - 
ILS  - 
IPD  - 

IPR  - 
IVS  - 
JPO  - 

Kbaud  - 
LLVS  - 


Environmental  Protection  Agency 
Essential  Task  Breakdown 
Effective  Translational  Lift 

Enhanced  Quality  Function  Deployment  A  second-general  Quality 
Function  Deployment  method  developed  by  Don  Clausing  at  the 
Massachusetts  institute  of  Technology. 

Executive  Committee.  A  formal  working  group  of  the  Georgia  Tech  Aerial 
Robotics  Design  Team  composed  of  the  lead  engineer  and  faculty  advisor 
from  each  participating  school  and  industrial  sponsors. 

Free-Flight  Rotorcraft  Research  Vehicle.  An  ongoing  research  project  being 
conducted  by  the  United  States  Army  Aerostructures  Directorate  in  Langley, 
Virginia. 

Guided  Systems  Technologies 
Georgia  Tech 

Georgia  Tech  Research  Institute 
High-Level  Vision  System 
Hertz 

Institute  for  Defense  Analyses.  Sponsor  of  one  of  the  original  Concurrent 
Engineering  studies  (Winner,  et  al). 

A  computer  simulation  package  which  includes  solid  modeling  capability. 
Integrated  Logistics  Subsystem 

Integrated  Product  Development  The  General  Dynamics  Fort  Worth- 
specific  implementation  of  quality  engineering. 

In  Progress  Review.  A  formal  design  review. 

Integrated  Vision  System 

Joint  Project  Office.  An  organization  established  to  jointly  monitor 
unmanned  aerial  vehicle  efforts  by  all  branches  of  service  within  the 
Department  of  Defense. 

Kilobaud 

Low-Level  Vision  System 
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ME  - 


Mechanical  Engineering 


MEP  -  Mission  Equipment  Package.  That  portion  of  Georgia  Tech's  system  which 
made  up  the  aircraft's  payload. 

MIT  -  MassachusettsInstituteofTechnology 

MPCS  -  Mission  Planning  and  Control  Station 

NiCd  -  Nickel-Cadmium 

ORM  -  Object  Retrieval  Mechanism 

PCB  -  Printed  Circuit  Board 

PDOM  -  Parameter  Design  Optimization  Methods.  Quality  methodology  developed 

by  Dr.  Genichi  Taguchi. 

PDS  -  Product  Definition  Specification 

QFD  -  Quality  Function  Deployment  A  graphical  mapping  technique  which 
deploys  the  customer's  desires  to  product  and  supporting  process. 

RAF  -  Roswell  Air  Force.  A  metro- Atlanta  radio-control  club. 

R/C  -  Radio-controlle 

RFP  -  Request  for  Proposal 

RPV  -  Remotely-Piloted  Vehicle 

SAS  -  Stability  Augmentation  System 

SE  -  Systems  Engineering 

SEMP  -  System  Engineering  Management  Plan 

SPC  -  Statistical  Process  Control. 

TACOM  -  Tank- Automotive  Command,  United  States  Army 

TANGO  -  A  circuit  board  layout  tool. 

TPM  -  Technical  Performance  Measures 

TQC  -  Total  Quality  Control.  The  Japanese  implementation  of  quality  engineering. 
UA  V  -  Unmanned  Aerial  Vehicle 

UT  -  University  of  Texas 
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VTOL  - 
WBS  - 
WREK  - 


Vertical  Take-Off  and  Landing 

Work  Breakdown  Structure 

Call  letters  for  Georgia  Tech's  campus  radio  station. 
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